You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Karl Pauls <ka...@gmail.com> on 2006/12/10 14:47:03 UTC
[VOTE] Apache Felix 0.8.0 Incubator Release
The Felix PPMC has voted on an incubator release and we would like to
call an Incubator PMC vote to get final approval.
We hope that this release represents the final step for Felix'
graduation, but wish to pursue this official incubator release since we
do not know how long graduation will take and feel it is important to
make a public release available. We hope to request graduation once this
incubator release is approved.
The candidate incubator release can be found here:
http://people.apache.org/~rickhall/felix-0.8.0-incubator.html
We ask that you please vote to approve this release:
[ ] +1 Approve the Felix 0.8.0-incubator release.
[ ] -1 Veto the release (please provide specific comments)
Thanks in advance for your effort in examining the release.
- The Felix Team
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jim Jagielski wrote:
>
> As long as 3 people within the PMC attest to its validity, the
> release can go out. AFAIK, only a legal veto can block
> a release. In most cases, of course, the community listens
> and responds to any -1 votes and tries to address them,
> if need be. Ignoring -1's is bad form. But with releases,
> -1 aren't vetoes.
But if vetoed *code* is in a release candidate, it cannot proceed.
You can't veto "this release isn't ready" or "it's not feature complete",
but you can point out "commit r484848 was vetoed, please reroll your
candidate with this commit reverted".
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 10, 2006, at 7:57 PM, Jason van Zyl wrote:
> On 10 Dec 06, at 6:40 PM 10 Dec 06, Roy T. Fielding wrote:
>
>> On Dec 10, 2006, at 5:47 AM, Karl Pauls wrote:
>>
>>> We ask that you please vote to approve this release:
>>>
>>> [ ] +1 Approve the Felix 0.8.0-incubator release.
>>> [ ] -1 Veto the release (please provide specific comments)
>>
>> BTW, this Veto thing is wrong. I've been meaning to mention it
>> since several podlings have used this template. It is not possible
>> to veto a release -- all releases are majority votes. +1 just means
>> yes and -1 means no.
>>
>
> Really?
>
> I thought that would be considered a technical thing? If you know a
> release is getting pushed out when it shouldn't because it's
> premature that on technical grounds you could say that it doesn't
> meet the requirements of a beta say? Or that it has know flaws and
> shouldn't be released?
>
> I honestly thought it was a technical type decision.
>
As long as 3 people within the PMC attest to its validity, the
release can go out. AFAIK, only a legal veto can block
a release. In most cases, of course, the community listens
and responds to any -1 votes and tries to address them,
if need be. Ignoring -1's is bad form. But with releases,
-1 aren't vetoes.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 11 December 2006 11:16, Craig L Russell wrote:
> My understanding is that a legal issue is sufficient to veto a
> release. So if an issue is raised, e.g. missing NOTICE or wrong
> copyright in the LICENSE, that should be a veto. But I agree that the
> fact that there is a legal issue raised is sufficient for the
> proposer to withdraw the proposal and try again.
>
> On the other hand, objecting to the contents of a release (missing
> feature, badly implemented feature) can result in a -1 without a veto.
Sounds very reasonable to me. However, if there is a disagreement of what
constitutes a legal flaw, then there is something much more serious going on
in the community. I.e. if person A doesn't manage to stop pmc B from a
release, then A should probably consult the legal-discuss@ and/or board@.
After all, it *could* be that B doesn't understand the legal requirements,
but worse if it is done on purpose to hurt the ASF...
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by Craig L Russell <Cr...@Sun.COM>.
On Dec 10, 2006, at 5:11 PM, Jason van Zyl wrote:
> On 10 Dec 06, at 8:02 PM 10 Dec 06, Martin Cooper wrote:
>
>> On 12/10/06, Jason van Zyl <ja...@maven.org> wrote:
>>>
>>> On 10 Dec 06, at 6:40 PM 10 Dec 06, Roy T. Fielding wrote:
>>>
>>> > On Dec 10, 2006, at 5:47 AM, Karl Pauls wrote:
>>> >
>>> >> We ask that you please vote to approve this release:
>>> >>
>>> >> [ ] +1 Approve the Felix 0.8.0-incubator release.
>>> >> [ ] -1 Veto the release (please provide specific comments)
>>> >
>>> > BTW, this Veto thing is wrong. I've been meaning to mention it
>>> > since several podlings have used this template. It is not
>>> possible
>>> > to veto a release -- all releases are majority votes. +1 just
>>> means
>>> > yes and -1 means no.
>>> >
>>>
>>> Really?
>>>
>>> I thought that would be considered a technical thing? If you know a
>>> release is getting pushed out when it shouldn't because it's
>>> premature that on technical grounds you could say that it doesn't
>>> meet the requirements of a beta say? Or that it has know flaws and
>>> shouldn't be released?
>>
>>
>> See the section on "Votes on Package Releases" here:
>>
>> http://www.apache.org/foundation/voting.html
>>
My understanding is that a legal issue is sufficient to veto a
release. So if an issue is raised, e.g. missing NOTICE or wrong
copyright in the LICENSE, that should be a veto. But I agree that the
fact that there is a legal issue raised is sufficient for the
proposer to withdraw the proposal and try again.
On the other hand, objecting to the contents of a release (missing
feature, badly implemented feature) can result in a -1 without a veto.
Craig
>
> Can a PMC chair veto a release?
>
> Jason.
>
>> --
>> Martin Cooper
>>
>>
>> I honestly thought it was a technical type decision.
>>>
>>> Jason.
>>>
>>> > ....Roy
>>> >
>>> >
>>> >
>>> --------------------------------------------------------------------
>>> -
>>> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> > For additional commands, e-mail: general-help@incubator.apache.org
>>> >
>>> >
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: release voting
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 20, 2006, at 3:12 PM, Roy T. Fielding wrote:
>
> If an officer believes that a release package should be "vetoed"
> for legal reasons, then they should inform infrastructure to remove
> the release from distribution. However, that doesn't change the
> fact that a release was cut, a version number assigned, and a decision
> made by the project to release. It may seem like a small twist on
> semantics, but I believe it to be an important one.
>
++1.
There's no such thing, really, as an un-released release :)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: release voting
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Roy T. Fielding wrote:
>
> If an officer believes that a release package should be "vetoed"
> for legal reasons, then they should inform infrastructure to remove
> the release from distribution.
Take that one step further...
s/officer/officer or member/
Any PMC member who discovers a legal violation should take immediate action,
inform the PMC, and inform the board that the situation had existed and how
it has been remedied.
Usually, if a package has an issue, infra will just move it from the web site
over to the creator's home directory. Likewise with svn, we do an rm, although
if we discover a major IP violation it's sometimes also necessary to remove the
offending code later from the history. You are a PMC member/committer so there
is nothing standing in your way from correcting the problem.
It's easy enough to restore if the 'issue' wasn't a problem.
I agree with Roy - a package can be taken down by the Chairman, but this is not
a VETO. If the chair raises a legal issue during a release vote, we trust most
PMC members will simply nod their heads and the vote doesn't pass (we also trust
the RM will do the same and the vote would never be tallied.)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: release voting
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Dec 20, 2006, at 3:20 AM, Niclas Hedhman wrote:
> On Wednesday 20 December 2006 18:04, Roy T. Fielding wrote:
>> On Dec 19, 2006, at 8:02 PM, Greg Stein wrote:
>>> That's how it works.
>
>> No, that's not how it works.
>
> Isn't it a bit scary that two of the most respected members of ASF
> don't agree
> on how ASF operates "when push come to shove" ?
No, it only proves that we aren't machines. The exact details of how
it all works are not written down because people are expected to use
their own judgement to handle exceptions gracefully and make the process
more fluid when there is clear agreement. For example, most of the PMC
decisions are not made by vote -- PMC members simply go along with what
the other members are doing until there is a disagreement, and the
formal
process only kicks in when consensus is unclear or when the legal risk
requires that a formal decision be recorded (as in release votes).
In any case, the board does have the ability to delegate additional
powers to an officer when that is believed to be good for the ASF.
The process can also change over time if needed. However, I think
we should operate on the principle that the power to make decisions
is vested in the committees, and it is only the power to implement
those decisions that the officers can wield as needed.
If an officer believes that a release package should be "vetoed"
for legal reasons, then they should inform infrastructure to remove
the release from distribution. However, that doesn't change the
fact that a release was cut, a version number assigned, and a decision
made by the project to release. It may seem like a small twist on
semantics, but I believe it to be an important one.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: release voting
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
On 12/20/06, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Wednesday 20 December 2006 18:04, Roy T. Fielding wrote:
> > On Dec 19, 2006, at 8:02 PM, Greg Stein wrote:
> > > That's how it works.
>
> > No, that's not how it works.
>
> Isn't it a bit scary that two of the most respected members of ASF don't agree
> on how ASF operates "when push come to shove" ?
To me this debate is the opposite of scary: it's good. I like this
discussion for two reasons. Firstis that it's well thought-out, it's
clear both these guys are well-informed and well-intentioned, which
makes for an educational debate for all the readers. Second is that
it shows our organization is robust enough to thrive in the
flexibility we gave such an important role as VP/PMC Chair.
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: release voting
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 20 December 2006 18:04, Roy T. Fielding wrote:
> On Dec 19, 2006, at 8:02 PM, Greg Stein wrote:
> > That's how it works.
> No, that's not how it works.
Isn't it a bit scary that two of the most respected members of ASF don't agree
on how ASF operates "when push come to shove" ?
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: release voting
Posted by Jim Jagielski <ji...@jaguNET.com>.
>
> The chair is not delegated authority over the projects -- only
> responsibility to manage the committee, and thus the only decisions
> that a chair can go hog-wild on are the establishment of unusual
> project bylaws or appointment and removal of committee members
> (which requires an ACK by a board member).
Considering that:
1. One of the most "legal" things a PMC does is
to release software and -
2. That the PMC is task with overseeing that and -
3. The Chair is tasked with managing the PMC and -
4. The Chair is an officer of the foundation
I would think that *with very VERY VERY* good reason,
the Chair could, if absolutely required, veto a release,
but it would only be for legal reasons and not
technical ones.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: release voting
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Dec 19, 2006, at 8:02 PM, Greg Stein wrote:
> On 12/11/06, Roy T. Fielding <fi...@gbiv.com> wrote:
>> ...
>> > Can a PMC chair veto a release?
>>
>> No. A chair only counts as one vote. A chair's only special powers
>> are to receive things officially and ensure that the PMC does vote.
>
> Euh... no. Nowhere is that stated in the ASF Bylaws. They're quite mum
> on what the Chair can do.
Yes, but Bylaws are subject to the General Corporation Law of the
State of Delaware
http://www.state.de.us/corp/DElaw.shtml
and committees, unless explicitly stated otherwise, are expected to
govern themselves under generally accepted codes of procedure. Like,
for example, "The Standard Code of Parliamentary Procedure, 4th ed."
or some variation on Robert's Rules. Both of them disagree with
your interpretation.
Officers can be delegated certain duties by the board, and once
delegated the officer has the implied power to do whatever is
necessary to carry out the functions and duties of that office.
But those duties must be specifically delegated in the resolution
or bylaws that create the office.
> The Chair *is* an officer of the corporation, though, and that implies
> a lot more than what you've stated. An officer can make binding
> decisions for the corporation. In the case of a project VP (the
> Chair), they can effectively do anything necessary within the realm of
> their project that is appropriate for that project. Consider:
>
> RESOLVED, that the office of Vice President, Apache Labs be and
> hereby is created, the person holding such office to serve at
> the direction of the Board of Directors as the chair of the
> Labs PMC, and to have primary responsibility for management of
> the projects within the scope of responsibility of the Apache
> Labs PMC; and be it further
The VP is delegated the duty of chair of a committee and primary
responsibility for management of the projects. *Everyone* knows that
the chair of a committee does not make decisions *for* the committee.
The resolution does not say that the VP makes project decisions or is
delegated authority over the project as a whole. The only reason for
the four paragraphs above it is to state that the board is delegating
that authority to a committee, not to a single person.
NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as Apache Labs, be
and hereby is established pursuant to Bylaws of the Foundation;
and be it further
That is the operative authority and it is not vested in the chair.
This specific type of delegation is defined by our Bylaws and is
specifically intended to be in the form of a committee, which
means that the decisions are made by committee decision.
The chair is not delegated authority over the projects -- only
responsibility to manage the committee, and thus the only decisions
that a chair can go hog-wild on are the establishment of unusual
project bylaws or appointment and removal of committee members
(which requires an ACK by a board member). The only way that the
VP can make unilateral decisions for the project is by first
removing the rest of the PMC -- otherwise, it is the committee
that is given authority to make project decisions, not the VP.
Putting it another way: there would be no reason to establish a
committee if decisions are to be made by the officer alone. Any
officer is capable of creating their own committees to delegate
their own duties (though not their responsibilities), so the board
resolution to do what you indicate would just appoint an officer
with both responsibility and authority and be done. The whole
reason for appointing a committee, and further to retain control
over the membership of the committee, is to have a committee duly
consider and act on project decisions rather than an individual.
> All of our TLP resolutions have that paragraph. With that paragraph,
> and VP status, I consider the Chairs to be able to do just about
> anything that is in the best interests of their project (and not
> counter to other interests of the ASF).
*shrug* I don't think that consideration is supported by either.
We'd probably have to get Drew Wright to judge what it means,
since he wrote the original paragraphs.
> The ASF Bylaws basically restate the above:
>
> "...the chairman of each Project Management Committee shall be
> primarily responsible for project(s) managed by such committee,
> and he or she shall establish rules and procedures for the day
> to day management of project(s) for which the committee is
> responsible."
>
> I've always interpreted the VP as the one to define the rules of the
> PMC. They are the actual "hand of power", but the Board expects them
> to operate that power in a certain way. If they misuse it... well,
> that's the end of that. Those expectations are things like voting
> procedures, consensus rules, blah blah blah. There is a cultural
> definition of *how* the VP should act, but when push comes to shove,
> I've told Chairs on a number of occasions, "dood. you're an officer of
> the corporation. *you* make it work. you have extremely wide leeway
> when it comes to handling your problems."
Those are all matters of project bylaws (how the committee operates),
not project decisions. Yes, the VP does have the power to act when
it comes to managing the committee.
This thread was not about managing the committee -- it was about
a release decision. A purely technical decision over which authority
has been specifically assigned to a committee. No chair has the right
to override decisions of the committee.
> When Ken dumped the entire Geronimo PMC, he did that under his rights
> as a VP of that project. He felt that was the appropriate action at
> the time. I believe he had every right/ability to do that, and the
> Board backed his right to do so. Now... if we saw Chairs doing that
> every other week, there'd be hell to pay. Again, there is an
> expectation of behavior, but there is actually very few written
> rules/restrictions.
>
> In this case, if we saw a Chair taking unilateral actions within a
> project, we'd call him to the carpet and demand an explanation. If he
> had a good one, then alright. That's how it works.
No, that's not how it works. If a chair makes a unilateral decision
for a project on a technical issue, then our project guidelines are
a bunch of rubbish. We have PMCs for a reason. It isn't pretty and
isn't the most efficient form of governance, but it balances the
powers sufficiently to keep our officers (and our board) from
getting too high off the fumes of power and wreaking havoc on the
long-term viability of our projects.
Checks, balances, and the principle of least authority are all
part of good governance. Probably the only way I could kill the
httpd project would be to start making decisions for it, even if
they all seem like good decisions at the time. Heck, even if
they all happen to be the best decisions possible, it would still
kill the project if others stopped thinking critically about the
products and simply waited for me to decide: death by atrophy.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: release voting
Posted by Greg Stein <gs...@gmail.com>.
On 12/11/06, Roy T. Fielding <fi...@gbiv.com> wrote:
>...
> > Can a PMC chair veto a release?
>
> No. A chair only counts as one vote. A chair's only special powers
> are to receive things officially and ensure that the PMC does vote.
Euh... no. Nowhere is that stated in the ASF Bylaws. They're quite mum
on what the Chair can do.
The Chair *is* an officer of the corporation, though, and that implies
a lot more than what you've stated. An officer can make binding
decisions for the corporation. In the case of a project VP (the
Chair), they can effectively do anything necessary within the realm of
their project that is appropriate for that project. Consider:
RESOLVED, that the office of Vice President, Apache Labs be and
hereby is created, the person holding such office to serve at
the direction of the Board of Directors as the chair of the
Labs PMC, and to have primary responsibility for management of
the projects within the scope of responsibility of the Apache
Labs PMC; and be it further
All of our TLP resolutions have that paragraph. With that paragraph,
and VP status, I consider the Chairs to be able to do just about
anything that is in the best interests of their project (and not
counter to other interests of the ASF).
The ASF Bylaws basically restate the above:
"...the chairman of each Project Management Committee shall be
primarily responsible for project(s) managed by such committee,
and he or she shall establish rules and procedures for the day
to day management of project(s) for which the committee is
responsible."
I've always interpreted the VP as the one to define the rules of the
PMC. They are the actual "hand of power", but the Board expects them
to operate that power in a certain way. If they misuse it... well,
that's the end of that. Those expectations are things like voting
procedures, consensus rules, blah blah blah. There is a cultural
definition of *how* the VP should act, but when push comes to shove,
I've told Chairs on a number of occasions, "dood. you're an officer of
the corporation. *you* make it work. you have extremely wide leeway
when it comes to handling your problems."
When Ken dumped the entire Geronimo PMC, he did that under his rights
as a VP of that project. He felt that was the appropriate action at
the time. I believe he had every right/ability to do that, and the
Board backed his right to do so. Now... if we saw Chairs doing that
every other week, there'd be hell to pay. Again, there is an
expectation of behavior, but there is actually very few written
rules/restrictions.
In this case, if we saw a Chair taking unilateral actions within a
project, we'd call him to the carpet and demand an explanation. If he
had a good one, then alright. That's how it works.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
release voting
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Dec 10, 2006, at 5:11 PM, Jason van Zyl wrote:
> On 10 Dec 06, at 8:02 PM 10 Dec 06, Martin Cooper wrote:
>> On 12/10/06, Jason van Zyl <ja...@maven.org> wrote:
>>> On 10 Dec 06, at 6:40 PM 10 Dec 06, Roy T. Fielding wrote:
>>>
>>> > On Dec 10, 2006, at 5:47 AM, Karl Pauls wrote:
>>> >
>>> >> We ask that you please vote to approve this release:
>>> >>
>>> >> [ ] +1 Approve the Felix 0.8.0-incubator release.
>>> >> [ ] -1 Veto the release (please provide specific comments)
>>> >
>>> > BTW, this Veto thing is wrong. I've been meaning to mention it
>>> > since several podlings have used this template. It is not
>>> possible
>>> > to veto a release -- all releases are majority votes. +1 just
>>> means
>>> > yes and -1 means no.
>>> >
>>>
>>> Really?
>>>
>>> I thought that would be considered a technical thing? If you know a
>>> release is getting pushed out when it shouldn't because it's
>>> premature that on technical grounds you could say that it doesn't
>>> meet the requirements of a beta say? Or that it has know flaws and
>>> shouldn't be released?
No. The only things that can be vetoed are specific changes, and the
veto must have a technical reason that is valid for that change.
Otherwise, one stubborn person can effectively kill a project simply
by vetoing every choice made by the group.
>> See the section on "Votes on Package Releases" here:
>>
>> http://www.apache.org/foundation/voting.html
Yow, more hopelessly vague wordings. Look at the original httpd voting
guidelines for a better picture.
> Can a PMC chair veto a release?
No. A chair only counts as one vote. A chair's only special powers
are to receive things officially and ensure that the PMC does vote.
They can stop a package from being published if it has not yet been
released by vote of the PMC, but they can't unilaterally decide to
release or unrelease a given package. If a chair wants such a thing,
they need to convince a majority of those voting to support their
position, just like any other majority decision.
Under no circumstances does a chair have any other special powers.
We burden the chair with infrastructure tasks just because we need
to delegate some of that work, not because we think they are making
decisions for the PMC. A project decision must be made by the project.
The responsibility assigned to the chair by the bylaws is to give one
person the responsibility to ensure that decisions are made by the
project and maintain communication with the board -- it is the PMC
that is given authority to make project decisions, not the chair.
An RM can choose not to upload a release, but the package is released
if the project votes to release it. Infrastructure or the Board can
remove a release from our websites if that is in the ASF's best
interests.
There is no "legal veto". If a legal problem is found with a package,
the ASF expects the responsible PMC members to change their own votes
in response to that discovery. If for some odd reason that does not
occur, the Board can direct infrastructure to do anything needed,
but it can't rewrite history -- the package has been released and
the most the ASF can do is make it hard to obtain by stopping our
own distribution mechanisms.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jason van Zyl wrote:
> Can a PMC chair veto a release?
IMO, yes, as per the ASF Bylaws. But I would expect people to have some
pretty strong feelings and reactions to such an action, so any PMC Chair who
does so ought to have pretty strong justification.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by Jason van Zyl <ja...@maven.org>.
On 10 Dec 06, at 8:02 PM 10 Dec 06, Martin Cooper wrote:
> On 12/10/06, Jason van Zyl <ja...@maven.org> wrote:
>>
>> On 10 Dec 06, at 6:40 PM 10 Dec 06, Roy T. Fielding wrote:
>>
>> > On Dec 10, 2006, at 5:47 AM, Karl Pauls wrote:
>> >
>> >> We ask that you please vote to approve this release:
>> >>
>> >> [ ] +1 Approve the Felix 0.8.0-incubator release.
>> >> [ ] -1 Veto the release (please provide specific comments)
>> >
>> > BTW, this Veto thing is wrong. I've been meaning to mention it
>> > since several podlings have used this template. It is not possible
>> > to veto a release -- all releases are majority votes. +1 just
>> means
>> > yes and -1 means no.
>> >
>>
>> Really?
>>
>> I thought that would be considered a technical thing? If you know a
>> release is getting pushed out when it shouldn't because it's
>> premature that on technical grounds you could say that it doesn't
>> meet the requirements of a beta say? Or that it has know flaws and
>> shouldn't be released?
>
>
> See the section on "Votes on Package Releases" here:
>
> http://www.apache.org/foundation/voting.html
>
Can a PMC chair veto a release?
Jason.
> --
> Martin Cooper
>
>
> I honestly thought it was a technical type decision.
>>
>> Jason.
>>
>> > ....Roy
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: general-help@incubator.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by Martin Cooper <ma...@apache.org>.
On 12/10/06, Jason van Zyl <ja...@maven.org> wrote:
>
> On 10 Dec 06, at 6:40 PM 10 Dec 06, Roy T. Fielding wrote:
>
> > On Dec 10, 2006, at 5:47 AM, Karl Pauls wrote:
> >
> >> We ask that you please vote to approve this release:
> >>
> >> [ ] +1 Approve the Felix 0.8.0-incubator release.
> >> [ ] -1 Veto the release (please provide specific comments)
> >
> > BTW, this Veto thing is wrong. I've been meaning to mention it
> > since several podlings have used this template. It is not possible
> > to veto a release -- all releases are majority votes. +1 just means
> > yes and -1 means no.
> >
>
> Really?
>
> I thought that would be considered a technical thing? If you know a
> release is getting pushed out when it shouldn't because it's
> premature that on technical grounds you could say that it doesn't
> meet the requirements of a beta say? Or that it has know flaws and
> shouldn't be released?
See the section on "Votes on Package Releases" here:
http://www.apache.org/foundation/voting.html
--
Martin Cooper
I honestly thought it was a technical type decision.
>
> Jason.
>
> > ....Roy
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by Jason van Zyl <ja...@maven.org>.
On 10 Dec 06, at 6:40 PM 10 Dec 06, Roy T. Fielding wrote:
> On Dec 10, 2006, at 5:47 AM, Karl Pauls wrote:
>
>> We ask that you please vote to approve this release:
>>
>> [ ] +1 Approve the Felix 0.8.0-incubator release.
>> [ ] -1 Veto the release (please provide specific comments)
>
> BTW, this Veto thing is wrong. I've been meaning to mention it
> since several podlings have used this template. It is not possible
> to veto a release -- all releases are majority votes. +1 just means
> yes and -1 means no.
>
Really?
I thought that would be considered a technical thing? If you know a
release is getting pushed out when it shouldn't because it's
premature that on technical grounds you could say that it doesn't
meet the requirements of a beta say? Or that it has know flaws and
shouldn't be released?
I honestly thought it was a technical type decision.
Jason.
> ....Roy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by "Roy T. Fielding" <ro...@gmail.com>.
On Dec 10, 2006, at 5:47 AM, Karl Pauls wrote:
> We ask that you please vote to approve this release:
>
> [ ] +1 Approve the Felix 0.8.0-incubator release.
> [ ] -1 Veto the release (please provide specific comments)
BTW, this Veto thing is wrong. I've been meaning to mention it
since several podlings have used this template. It is not possible
to veto a release -- all releases are majority votes. +1 just means
yes and -1 means no.
....Roy
Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by "Roy T. Fielding" <ro...@gmail.com>.
On Dec 10, 2006, at 5:47 AM, Karl Pauls wrote:
> We ask that you please vote to approve this release:
>
> [ ] +1 Approve the Felix 0.8.0-incubator release.
> [ ] -1 Veto the release (please provide specific comments)
BTW, this Veto thing is wrong. I've been meaning to mention it
since several podlings have used this template. It is not possible
to veto a release -- all releases are majority votes. +1 just means
yes and -1 means no.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by Karl Pauls <ka...@gmail.com>.
Richard S. Hall wrote:
> Daniel Kulp wrote:
> > I'm not going to vote (would be non-binding anyway), but some issues I see:
> >
> > 1) The felix.jar itself does not have the DISCLAIMER in it. I think that's
> > fine as long as you don't plan on putting it in any maven repository. That
> > said, being a maven user, I'd like to see it fixed so it COULD be deployed
> > there.
>
> Yes, we can include that.
Sure, we can include a separate DISCLAIMER file. Note, however, that
in this case the DISCLAIMER is included in the NOTICE (which I believe
to be acceptable) but I agree that it might be more obvious in a
separate file.
> > 4) I don't see and asc files on the web page. The release needs to be signed
> > and KEYS made available.
>
> Yes, we were aware of this step, but we not clear on how to proceed with
> it. Perhaps Karl Pauls has a few more comments on that topic.
For me, it is somewhat unclear whether the signing should be done
before or after general@ is approached. I was under the assumption the
we need to sign the release after it is approved by the IPMC. Maybe
somebody can help me out on this one?
> Thanks for the feedback.
>
> -> richard
> > Dan
Indeed, thanks for the feedback. We will fix the missing LICENSE and
NOTICE files asap and change their location to META-INF.
Again, if the consensus is that we should sign the release before it
is approved by the IPMC then please let me know.
regards,
Karl
--
Karl Pauls
karlpauls@gmail.com
Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Richard S. Hall wrote:
>> 3) None of the three jars in bundle directory have the
>> license,notice, or disclaimer files.
>>
>
> D'oh! The LICENSE and NOTICE files are in the src/main/resources/
> directories for each of these bundles, but for some reason they are
> not getting copied into the resulting JAR files. I would imagine that
> we recently introduced a bug into our Maven bundle plugin (it was
> updated this last week) that is somehow interfering in this process.
> Sorry about that. I will look into the cause of this.
Quick follow up, I found the bug in our plugin...it has to do with
relative directories. If we build in the bundle subproject directory, it
correctly gets the LICENSE and NOTICE files. If we build in the parent
project directory, then it does not. We will obviously have to resolve
this. We must have earlier run RAT on JARs that were made from the
subproject directory...that will teach us for not double checking.
-> richard
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Richard S. Hall wrote:
>> 3) None of the three jars in bundle directory have the
>> license,notice, or disclaimer files.
>>
>
> D'oh! The LICENSE and NOTICE files are in the src/main/resources/
> directories for each of these bundles, but for some reason they are
> not getting copied into the resulting JAR files. I would imagine that
> we recently introduced a bug into our Maven bundle plugin (it was
> updated this last week) that is somehow interfering in this process.
> Sorry about that. I will look into the cause of this.
Quick follow up, I found the bug in our plugin...it has to do with
relative directories. If we build in the bundle subproject directory, it
correctly gets the LICENSE and NOTICE files. If we build in the parent
project directory, then it does not. We will obviously have to resolve
this. We must have earlier run RAT on JARs that were made from the
subproject directory...that will teach us for not double checking.
-> richard
Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Daniel Kulp wrote:
> I'm not going to vote (would be non-binding anyway), but some issues I see:
>
> 1) The felix.jar itself does not have the DISCLAIMER in it. I think that's
> fine as long as you don't plan on putting it in any maven repository. That
> said, being a maven user, I'd like to see it fixed so it COULD be deployed
> there.
>
Yes, we can include that.
> 2) The LICENSE and NOTICE files in the felix jar are right in the root of the
> jar. I think we've been recommending they go into the META-INF dir.
>
We can place these where ever people suggest is best.
> 3) None of the three jars in bundle directory have the license,notice, or
> disclaimer files.
>
D'oh! The LICENSE and NOTICE files are in the src/main/resources/
directories for each of these bundles, but for some reason they are not
getting copied into the resulting JAR files. I would imagine that we
recently introduced a bug into our Maven bundle plugin (it was updated
this last week) that is somehow interfering in this process. Sorry about
that. I will look into the cause of this.
> 4) I don't see and asc files on the web page. The release needs to be signed
> and KEYS made available.
>
Yes, we were aware of this step, but we not clear on how to proceed with
it. Perhaps Karl Pauls has a few more comments on that topic.
Thanks for the feedback.
-> richard
> Dan
>
>
> On Sunday 10 December 2006 08:47, Karl Pauls wrote:
>
>> The Felix PPMC has voted on an incubator release and we would like to
>> call an Incubator PMC vote to get final approval.
>>
>> We hope that this release represents the final step for Felix'
>> graduation, but wish to pursue this official incubator release since we
>> do not know how long graduation will take and feel it is important to
>> make a public release available. We hope to request graduation once this
>> incubator release is approved.
>>
>> The candidate incubator release can be found here:
>>
>> http://people.apache.org/~rickhall/felix-0.8.0-incubator.html
>>
>> We ask that you please vote to approve this release:
>>
>> [ ] +1 Approve the Felix 0.8.0-incubator release.
>> [ ] -1 Veto the release (please provide specific comments)
>>
>> Thanks in advance for your effort in examining the release.
>>
>> - The Felix Team
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
Re: Re: Re: Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by Karl Pauls <ka...@gmail.com>.
> > The asc and KEYS files are available on the page now.
> >
> > Please start reviewing our release again. The URL stays the same:
> >
> > http://people.apache.org/~rickhall/felix-0.8.0-incubator.html
>
> +1
>
> -- minor (fix in HEAD) --
>
> a number of package.html's are IMHO creative enough to be
> copyrightable. i think that they should have copyright headers.
Well, the point is that this package.html's are from the OSGi alliance
(licensed under ASL). We redistribute them but try not to modify them.
We've been discussing adding a copyright but decided against it on the
grounds of them being provided like this.
> - notes and comments (not requirements) -
>
> the public key does not seems to be available from the major
> keysigning networks (see
> http://www.apache.org/dev/release-signing.html if you haven't uploaded
> it yet)
I'm going to upload the key. Thanks.
> good practice to produce both tar.gz and zip compressed artifacts.
> yes, i know that most major platforms can easily open either format
> but users associated tar.gz with *nix and zip with m$. producing both
> formats is good psychology.
Right, we will look into it.
> release notes are an important form of guerilla advertising. the same
> content can be used in several different places: on the download page,
> on announcements, on grassroots media (eg freshmeat) and as plain text
> in the release. consider adding some next time.
>
> - robert
We will. Due to this being our first release it wouldn't contain much
this time around anyhow, but I agree, release notes are important.
Thanks for pointing it out and for reviewing.
regards,
Karl
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Re: Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by robert burrell donkin <ro...@gmail.com>.
On 12/12/06, Karl Pauls <ka...@gmail.com> wrote:
> The asc and KEYS files are available on the page now.
>
> Please start reviewing our release again. The URL stays the same:
>
> http://people.apache.org/~rickhall/felix-0.8.0-incubator.html
+1
-- minor (fix in HEAD) --
a number of package.html's are IMHO creative enough to be
copyrightable. i think that they should have copyright headers.
- notes and comments (not requirements) -
the public key does not seems to be available from the major
keysigning networks (see
http://www.apache.org/dev/release-signing.html if you haven't uploaded
it yet)
good practice to produce both tar.gz and zip compressed artifacts.
yes, i know that most major platforms can easily open either format
but users associated tar.gz with *nix and zip with m$. producing both
formats is good psychology.
MANIFEST.MF lacks some of the attributes recommended by Sun
(Extension-Name, Specification-Title, Specification-Vendor,
Specification-Version, Implementation-Vendor-Id, Implementation-Title,
Implementation-Vendor, Implementation-Version)
release notes are an important form of guerilla advertising. the same
content can be used in several different places: on the download page,
on announcements, on grassroots media (eg freshmeat) and as plain text
in the release. consider adding some next time.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Re: Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by Enrique Rodriguez <en...@gmail.com>.
On 12/12/06, Karl Pauls <ka...@gmail.com> wrote:
> The asc and KEYS files are available on the page now.
>
> Please start reviewing our release again. The URL stays the same:
>
> http://people.apache.org/~rickhall/felix-0.8.0-incubator.html
Robert's "notes and comments" are duly noted by the Felix community.
Thanks for reviewing.
I'm +1 (non-binding).
Enrique
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
[RESULT] Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by Karl Pauls <ka...@gmail.com>.
This vote has been open for more than 72 hours, so we would like to
call the vote on Felix-0.8.0-incubator so that we can move forward:
* +1 votes from Robert Burrell Donkin, Upayavira,
Enrique Rodriguez, Alex Karasulu
* No 0 votes.
* No -1 votes.
With three +1 from IPMC members the vote is successful. We will make
an official announcement and make the release available publicly.
Thanks to the people who reviewed and/or voted.
regards,
Karl
--
Karl Pauls
karlpauls@gmail.com
[RESULT] Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by Karl Pauls <ka...@gmail.com>.
This vote has been open for more than 72 hours, so we would like to
call the vote on Felix-0.8.0-incubator so that we can move forward:
* +1 votes from Robert Burrell Donkin, Upayavira,
Enrique Rodriguez, Alex Karasulu
* No 0 votes.
* No -1 votes.
With three +1 from IPMC members the vote is successful. We will make
an official announcement and make the release available publicly.
Thanks to the people who reviewed and/or voted.
regards,
Karl
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by Alex Karasulu <ao...@bellsouth.net>.
Upayavira wrote:
> Karl Pauls wrote:
>> The asc and KEYS files are available on the page now.
>>
>> Please start reviewing our release again. The URL stays the same:
>>
>> http://people.apache.org/~rickhall/felix-0.8.0-incubator.html
>>
>> regards,
>>
>> Karl
>>
>> On 12/12/06, Karl Pauls <ka...@gmail.com> wrote:
>>> > > > Not quite there yet. The incubator DISCLAIMER file is still
>>> missing from the
>>> > > > jars. That would prevent them going into maven repositories.
>>> > >
>>> > > Is that just a recommendation or a requirement? Our NOTICE files
>>> contain
>>> > > the incubator disclaimer text.
>>> >
>>> > it's a requirement that the text is present but AIUI in the NOTICE is
>>> > ok (though perhaps a separate DISCLAIMER is clear)
>>>
>>> We have a separate DISCLAIMER on top-level. The "binaries" (i.e., jar
>>> files) contain a NOTICE that includes the DISCLAIMER. I agree that a
>>> separate DISCLAIMER is more clear but I think for this release we'll
>>> go with the current set-up.
>>>
>>> > please let me know whether you plan to cut another candidate or
>>> > whether i should review the one above
>>>
>>> Yes, please review the one above.
>>>
>>> > signing the releases is a requirement. having a well connected code
>>> > signing key is definitely good but not mandatory
>>> >
>>> > - robert
>>>
>>> We will make the asc and KEYS files available on the page mentioned
>>> above asap (i.e., a couple of hours).
>
> Okay. I have looked around the release, and to the best of my (at this
> point) limited knowledge, everything looks in order.
>
> I have verified that the MD5 and PGP signature are correct.
>
> Therefore I am prepared to vote +1.
I just looked it over. Looks good wrt incubator rules. However I did
not have time to run Felix.
+1
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by Upayavira <uv...@odoko.co.uk>.
Karl Pauls wrote:
> The asc and KEYS files are available on the page now.
>
> Please start reviewing our release again. The URL stays the same:
>
> http://people.apache.org/~rickhall/felix-0.8.0-incubator.html
>
> regards,
>
> Karl
>
> On 12/12/06, Karl Pauls <ka...@gmail.com> wrote:
>> > > > Not quite there yet. The incubator DISCLAIMER file is still
>> missing from the
>> > > > jars. That would prevent them going into maven repositories.
>> > >
>> > > Is that just a recommendation or a requirement? Our NOTICE files
>> contain
>> > > the incubator disclaimer text.
>> >
>> > it's a requirement that the text is present but AIUI in the NOTICE is
>> > ok (though perhaps a separate DISCLAIMER is clear)
>>
>> We have a separate DISCLAIMER on top-level. The "binaries" (i.e., jar
>> files) contain a NOTICE that includes the DISCLAIMER. I agree that a
>> separate DISCLAIMER is more clear but I think for this release we'll
>> go with the current set-up.
>>
>> > please let me know whether you plan to cut another candidate or
>> > whether i should review the one above
>>
>> Yes, please review the one above.
>>
>> > signing the releases is a requirement. having a well connected code
>> > signing key is definitely good but not mandatory
>> >
>> > - robert
>>
>> We will make the asc and KEYS files available on the page mentioned
>> above asap (i.e., a couple of hours).
Okay. I have looked around the release, and to the best of my (at this
point) limited knowledge, everything looks in order.
I have verified that the MD5 and PGP signature are correct.
Therefore I am prepared to vote +1.
Regards, Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Re: Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by Karl Pauls <ka...@gmail.com>.
The asc and KEYS files are available on the page now.
Please start reviewing our release again. The URL stays the same:
http://people.apache.org/~rickhall/felix-0.8.0-incubator.html
regards,
Karl
On 12/12/06, Karl Pauls <ka...@gmail.com> wrote:
> > > > Not quite there yet. The incubator DISCLAIMER file is still missing from the
> > > > jars. That would prevent them going into maven repositories.
> > >
> > > Is that just a recommendation or a requirement? Our NOTICE files contain
> > > the incubator disclaimer text.
> >
> > it's a requirement that the text is present but AIUI in the NOTICE is
> > ok (though perhaps a separate DISCLAIMER is clear)
>
> We have a separate DISCLAIMER on top-level. The "binaries" (i.e., jar
> files) contain a NOTICE that includes the DISCLAIMER. I agree that a
> separate DISCLAIMER is more clear but I think for this release we'll
> go with the current set-up.
>
> > please let me know whether you plan to cut another candidate or
> > whether i should review the one above
>
> Yes, please review the one above.
>
> > signing the releases is a requirement. having a well connected code
> > signing key is definitely good but not mandatory
> >
> > - robert
>
> We will make the asc and KEYS files available on the page mentioned
> above asap (i.e., a couple of hours).
>
> regards,
>
> Karl
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by Karl Pauls <ka...@gmail.com>.
> > > Not quite there yet. The incubator DISCLAIMER file is still missing from the
> > > jars. That would prevent them going into maven repositories.
> >
> > Is that just a recommendation or a requirement? Our NOTICE files contain
> > the incubator disclaimer text.
>
> it's a requirement that the text is present but AIUI in the NOTICE is
> ok (though perhaps a separate DISCLAIMER is clear)
We have a separate DISCLAIMER on top-level. The "binaries" (i.e., jar
files) contain a NOTICE that includes the DISCLAIMER. I agree that a
separate DISCLAIMER is more clear but I think for this release we'll
go with the current set-up.
> please let me know whether you plan to cut another candidate or
> whether i should review the one above
Yes, please review the one above.
> signing the releases is a requirement. having a well connected code
> signing key is definitely good but not mandatory
>
> - robert
We will make the asc and KEYS files available on the page mentioned
above asap (i.e., a couple of hours).
regards,
Karl
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by robert burrell donkin <ro...@gmail.com>.
On 12/11/06, Richard S. Hall <he...@ungoverned.org> wrote:
> Daniel Kulp wrote:
> > On Monday 11 December 2006 10:57, Richard S. Hall wrote:
> >
> >> As a follow up, we resolved every issue raised by Daniel except the
> >> signing portion. A new snapshot of the release is available at:
> >>
> >> http://people.apache.org/~rickhall/felix-0.8.0-incubator.html
> >>
> >> I was able to fix one minor bug in our maven bundle plugin that was
> >> causing LICENSE/NOTICE files to not get copied.
> >>
> >
> > Not quite there yet. The incubator DISCLAIMER file is still missing from the
> > jars. That would prevent them going into maven repositories.
> >
>
> Is that just a recommendation or a requirement? Our NOTICE files contain
> the incubator disclaimer text.
it's a requirement that the text is present but AIUI in the NOTICE is
ok (though perhaps a separate DISCLAIMER is clear)
please let me know whether you plan to cut another candidate or
whether i should review the one above
> > For the signing part, you really need gnupg installed. Create a key if you
> > don't already have one. (I think it's "gpg --gen-key", but it's been a while
> > since I looked into that part) Then you just need to run "gpg -a -s
> > filename.tar.gz" to produce the asc files.
> >
> > You would also need to do:
> > gpg --list-keys "username" > KEYS
> > gpg -a --export "username" >> KEYS
> >
> > and get that KEYS file added into the root of your SVN repository. Ideally,
> > you would also upload it to one of the public keyservers as well. Longer
> > term, you should also attend an apache keysigning party or similar to get
> > your keys signed by enough "apache people" so that apache people can trust
> > that those keys really are yours.
> >
>
> Thanks for this info. We will work on it.
see http://www.apache.org/dev/release-signing.html
signing the releases is a requirement. having a well connected code
signing key is definitely good but not mandatory
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Daniel Kulp wrote:
> On Monday 11 December 2006 10:57, Richard S. Hall wrote:
>
>> As a follow up, we resolved every issue raised by Daniel except the
>> signing portion. A new snapshot of the release is available at:
>>
>> http://people.apache.org/~rickhall/felix-0.8.0-incubator.html
>>
>> I was able to fix one minor bug in our maven bundle plugin that was
>> causing LICENSE/NOTICE files to not get copied.
>>
>
> Not quite there yet. The incubator DISCLAIMER file is still missing from the
> jars. That would prevent them going into maven repositories.
>
Is that just a recommendation or a requirement? Our NOTICE files contain
the incubator disclaimer text.
> For the signing part, you really need gnupg installed. Create a key if you
> don't already have one. (I think it's "gpg --gen-key", but it's been a while
> since I looked into that part) Then you just need to run "gpg -a -s
> filename.tar.gz" to produce the asc files.
>
> You would also need to do:
> gpg --list-keys "username" > KEYS
> gpg -a --export "username" >> KEYS
>
> and get that KEYS file added into the root of your SVN repository. Ideally,
> you would also upload it to one of the public keyservers as well. Longer
> term, you should also attend an apache keysigning party or similar to get
> your keys signed by enough "apache people" so that apache people can trust
> that those keys really are yours.
>
Thanks for this info. We will work on it.
-> richard
>
> Dan
>
>
>
>
>> Hopefully the majority vote can continue...
>>
>> -> richard
>>
>> Daniel Kulp wrote:
>>
>>> I'm not going to vote (would be non-binding anyway), but some issues I
>>> see:
>>>
>>> 1) The felix.jar itself does not have the DISCLAIMER in it. I think
>>> that's fine as long as you don't plan on putting it in any maven
>>> repository. That said, being a maven user, I'd like to see it fixed so
>>> it COULD be deployed there.
>>>
>>> 2) The LICENSE and NOTICE files in the felix jar are right in the root of
>>> the jar. I think we've been recommending they go into the META-INF dir.
>>>
>>> 3) None of the three jars in bundle directory have the license,notice, or
>>> disclaimer files.
>>>
>>> 4) I don't see and asc files on the web page. The release needs to be
>>> signed and KEYS made available.
>>>
>>> Dan
>>>
>>> On Sunday 10 December 2006 08:47, Karl Pauls wrote:
>>>
>>>> The Felix PPMC has voted on an incubator release and we would like to
>>>> call an Incubator PMC vote to get final approval.
>>>>
>>>> We hope that this release represents the final step for Felix'
>>>> graduation, but wish to pursue this official incubator release since we
>>>> do not know how long graduation will take and feel it is important to
>>>> make a public release available. We hope to request graduation once this
>>>> incubator release is approved.
>>>>
>>>> The candidate incubator release can be found here:
>>>>
>>>> http://people.apache.org/~rickhall/felix-0.8.0-incubator.html
>>>>
>>>> We ask that you please vote to approve this release:
>>>>
>>>> [ ] +1 Approve the Felix 0.8.0-incubator release.
>>>> [ ] -1 Veto the release (please provide specific comments)
>>>>
>>>> Thanks in advance for your effort in examining the release.
>>>>
>>>> - The Felix Team
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by Daniel Kulp <da...@iona.com>.
On Monday 11 December 2006 10:57, Richard S. Hall wrote:
> As a follow up, we resolved every issue raised by Daniel except the
> signing portion. A new snapshot of the release is available at:
>
> http://people.apache.org/~rickhall/felix-0.8.0-incubator.html
>
> I was able to fix one minor bug in our maven bundle plugin that was
> causing LICENSE/NOTICE files to not get copied.
Not quite there yet. The incubator DISCLAIMER file is still missing from the
jars. That would prevent them going into maven repositories.
For the signing part, you really need gnupg installed. Create a key if you
don't already have one. (I think it's "gpg --gen-key", but it's been a while
since I looked into that part) Then you just need to run "gpg -a -s
filename.tar.gz" to produce the asc files.
You would also need to do:
gpg --list-keys "username" > KEYS
gpg -a --export "username" >> KEYS
and get that KEYS file added into the root of your SVN repository. Ideally,
you would also upload it to one of the public keyservers as well. Longer
term, you should also attend an apache keysigning party or similar to get
your keys signed by enough "apache people" so that apache people can trust
that those keys really are yours.
Dan
> Hopefully the majority vote can continue...
>
> -> richard
>
> Daniel Kulp wrote:
> > I'm not going to vote (would be non-binding anyway), but some issues I
> > see:
> >
> > 1) The felix.jar itself does not have the DISCLAIMER in it. I think
> > that's fine as long as you don't plan on putting it in any maven
> > repository. That said, being a maven user, I'd like to see it fixed so
> > it COULD be deployed there.
> >
> > 2) The LICENSE and NOTICE files in the felix jar are right in the root of
> > the jar. I think we've been recommending they go into the META-INF dir.
> >
> > 3) None of the three jars in bundle directory have the license,notice, or
> > disclaimer files.
> >
> > 4) I don't see and asc files on the web page. The release needs to be
> > signed and KEYS made available.
> >
> > Dan
> >
> > On Sunday 10 December 2006 08:47, Karl Pauls wrote:
> >> The Felix PPMC has voted on an incubator release and we would like to
> >> call an Incubator PMC vote to get final approval.
> >>
> >> We hope that this release represents the final step for Felix'
> >> graduation, but wish to pursue this official incubator release since we
> >> do not know how long graduation will take and feel it is important to
> >> make a public release available. We hope to request graduation once this
> >> incubator release is approved.
> >>
> >> The candidate incubator release can be found here:
> >>
> >> http://people.apache.org/~rickhall/felix-0.8.0-incubator.html
> >>
> >> We ask that you please vote to approve this release:
> >>
> >> [ ] +1 Approve the Felix 0.8.0-incubator release.
> >> [ ] -1 Veto the release (please provide specific comments)
> >>
> >> Thanks in advance for your effort in examining the release.
> >>
> >> - The Felix Team
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by "Richard S. Hall" <he...@ungoverned.org>.
As a follow up, we resolved every issue raised by Daniel except the
signing portion. A new snapshot of the release is available at:
http://people.apache.org/~rickhall/felix-0.8.0-incubator.html
I was able to fix one minor bug in our maven bundle plugin that was
causing LICENSE/NOTICE files to not get copied.
Hopefully the majority vote can continue...
-> richard
Daniel Kulp wrote:
> I'm not going to vote (would be non-binding anyway), but some issues I see:
>
> 1) The felix.jar itself does not have the DISCLAIMER in it. I think that's
> fine as long as you don't plan on putting it in any maven repository. That
> said, being a maven user, I'd like to see it fixed so it COULD be deployed
> there.
>
> 2) The LICENSE and NOTICE files in the felix jar are right in the root of the
> jar. I think we've been recommending they go into the META-INF dir.
>
> 3) None of the three jars in bundle directory have the license,notice, or
> disclaimer files.
>
> 4) I don't see and asc files on the web page. The release needs to be signed
> and KEYS made available.
>
> Dan
>
>
> On Sunday 10 December 2006 08:47, Karl Pauls wrote:
>
>> The Felix PPMC has voted on an incubator release and we would like to
>> call an Incubator PMC vote to get final approval.
>>
>> We hope that this release represents the final step for Felix'
>> graduation, but wish to pursue this official incubator release since we
>> do not know how long graduation will take and feel it is important to
>> make a public release available. We hope to request graduation once this
>> incubator release is approved.
>>
>> The candidate incubator release can be found here:
>>
>> http://people.apache.org/~rickhall/felix-0.8.0-incubator.html
>>
>> We ask that you please vote to approve this release:
>>
>> [ ] +1 Approve the Felix 0.8.0-incubator release.
>> [ ] -1 Veto the release (please provide specific comments)
>>
>> Thanks in advance for your effort in examining the release.
>>
>> - The Felix Team
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by Daniel Kulp <da...@iona.com>.
One more:
5) In the README and the felix-usage.html file, it's only ever referred to
as "Felix." It's never referred to as "Apache Felix". There also isn't
anything about it being incubating. Just in the disclaimer file.
Dan
On Sunday 10 December 2006 09:39, Daniel Kulp wrote:
> I'm not going to vote (would be non-binding anyway), but some issues I see:
>
> 1) The felix.jar itself does not have the DISCLAIMER in it. I think
> that's fine as long as you don't plan on putting it in any maven
> repository. That said, being a maven user, I'd like to see it fixed so it
> COULD be deployed there.
>
> 2) The LICENSE and NOTICE files in the felix jar are right in the root of
> the jar. I think we've been recommending they go into the META-INF dir.
>
> 3) None of the three jars in bundle directory have the license,notice, or
> disclaimer files.
>
> 4) I don't see and asc files on the web page. The release needs to be
> signed and KEYS made available.
>
> Dan
>
> On Sunday 10 December 2006 08:47, Karl Pauls wrote:
> > The Felix PPMC has voted on an incubator release and we would like to
> > call an Incubator PMC vote to get final approval.
> >
> > We hope that this release represents the final step for Felix'
> > graduation, but wish to pursue this official incubator release since we
> > do not know how long graduation will take and feel it is important to
> > make a public release available. We hope to request graduation once this
> > incubator release is approved.
> >
> > The candidate incubator release can be found here:
> >
> > http://people.apache.org/~rickhall/felix-0.8.0-incubator.html
> >
> > We ask that you please vote to approve this release:
> >
> > [ ] +1 Approve the Felix 0.8.0-incubator release.
> > [ ] -1 Veto the release (please provide specific comments)
> >
> > Thanks in advance for your effort in examining the release.
> >
> > - The Felix Team
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by Daniel Kulp <da...@iona.com>.
One more:
5) In the README and the felix-usage.html file, it's only ever referred to
as "Felix." It's never referred to as "Apache Felix". There also isn't
anything about it being incubating. Just in the disclaimer file.
Dan
On Sunday 10 December 2006 09:39, Daniel Kulp wrote:
> I'm not going to vote (would be non-binding anyway), but some issues I see:
>
> 1) The felix.jar itself does not have the DISCLAIMER in it. I think
> that's fine as long as you don't plan on putting it in any maven
> repository. That said, being a maven user, I'd like to see it fixed so it
> COULD be deployed there.
>
> 2) The LICENSE and NOTICE files in the felix jar are right in the root of
> the jar. I think we've been recommending they go into the META-INF dir.
>
> 3) None of the three jars in bundle directory have the license,notice, or
> disclaimer files.
>
> 4) I don't see and asc files on the web page. The release needs to be
> signed and KEYS made available.
>
> Dan
>
> On Sunday 10 December 2006 08:47, Karl Pauls wrote:
> > The Felix PPMC has voted on an incubator release and we would like to
> > call an Incubator PMC vote to get final approval.
> >
> > We hope that this release represents the final step for Felix'
> > graduation, but wish to pursue this official incubator release since we
> > do not know how long graduation will take and feel it is important to
> > make a public release available. We hope to request graduation once this
> > incubator release is approved.
> >
> > The candidate incubator release can be found here:
> >
> > http://people.apache.org/~rickhall/felix-0.8.0-incubator.html
> >
> > We ask that you please vote to approve this release:
> >
> > [ ] +1 Approve the Felix 0.8.0-incubator release.
> > [ ] -1 Veto the release (please provide specific comments)
> >
> > Thanks in advance for your effort in examining the release.
> >
> > - The Felix Team
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Daniel Kulp wrote:
> I'm not going to vote (would be non-binding anyway), but some issues I see:
>
> 1) The felix.jar itself does not have the DISCLAIMER in it. I think that's
> fine as long as you don't plan on putting it in any maven repository. That
> said, being a maven user, I'd like to see it fixed so it COULD be deployed
> there.
>
Yes, we can include that.
> 2) The LICENSE and NOTICE files in the felix jar are right in the root of the
> jar. I think we've been recommending they go into the META-INF dir.
>
We can place these where ever people suggest is best.
> 3) None of the three jars in bundle directory have the license,notice, or
> disclaimer files.
>
D'oh! The LICENSE and NOTICE files are in the src/main/resources/
directories for each of these bundles, but for some reason they are not
getting copied into the resulting JAR files. I would imagine that we
recently introduced a bug into our Maven bundle plugin (it was updated
this last week) that is somehow interfering in this process. Sorry about
that. I will look into the cause of this.
> 4) I don't see and asc files on the web page. The release needs to be signed
> and KEYS made available.
>
Yes, we were aware of this step, but we not clear on how to proceed with
it. Perhaps Karl Pauls has a few more comments on that topic.
Thanks for the feedback.
-> richard
> Dan
>
>
> On Sunday 10 December 2006 08:47, Karl Pauls wrote:
>
>> The Felix PPMC has voted on an incubator release and we would like to
>> call an Incubator PMC vote to get final approval.
>>
>> We hope that this release represents the final step for Felix'
>> graduation, but wish to pursue this official incubator release since we
>> do not know how long graduation will take and feel it is important to
>> make a public release available. We hope to request graduation once this
>> incubator release is approved.
>>
>> The candidate incubator release can be found here:
>>
>> http://people.apache.org/~rickhall/felix-0.8.0-incubator.html
>>
>> We ask that you please vote to approve this release:
>>
>> [ ] +1 Approve the Felix 0.8.0-incubator release.
>> [ ] -1 Veto the release (please provide specific comments)
>>
>> Thanks in advance for your effort in examining the release.
>>
>> - The Felix Team
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by Daniel Kulp <da...@iona.com>.
I'm not going to vote (would be non-binding anyway), but some issues I see:
1) The felix.jar itself does not have the DISCLAIMER in it. I think that's
fine as long as you don't plan on putting it in any maven repository. That
said, being a maven user, I'd like to see it fixed so it COULD be deployed
there.
2) The LICENSE and NOTICE files in the felix jar are right in the root of the
jar. I think we've been recommending they go into the META-INF dir.
3) None of the three jars in bundle directory have the license,notice, or
disclaimer files.
4) I don't see and asc files on the web page. The release needs to be signed
and KEYS made available.
Dan
On Sunday 10 December 2006 08:47, Karl Pauls wrote:
> The Felix PPMC has voted on an incubator release and we would like to
> call an Incubator PMC vote to get final approval.
>
> We hope that this release represents the final step for Felix'
> graduation, but wish to pursue this official incubator release since we
> do not know how long graduation will take and feel it is important to
> make a public release available. We hope to request graduation once this
> incubator release is approved.
>
> The candidate incubator release can be found here:
>
> http://people.apache.org/~rickhall/felix-0.8.0-incubator.html
>
> We ask that you please vote to approve this release:
>
> [ ] +1 Approve the Felix 0.8.0-incubator release.
> [ ] -1 Veto the release (please provide specific comments)
>
> Thanks in advance for your effort in examining the release.
>
> - The Felix Team
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Posted by Daniel Kulp <da...@iona.com>.
I'm not going to vote (would be non-binding anyway), but some issues I see:
1) The felix.jar itself does not have the DISCLAIMER in it. I think that's
fine as long as you don't plan on putting it in any maven repository. That
said, being a maven user, I'd like to see it fixed so it COULD be deployed
there.
2) The LICENSE and NOTICE files in the felix jar are right in the root of the
jar. I think we've been recommending they go into the META-INF dir.
3) None of the three jars in bundle directory have the license,notice, or
disclaimer files.
4) I don't see and asc files on the web page. The release needs to be signed
and KEYS made available.
Dan
On Sunday 10 December 2006 08:47, Karl Pauls wrote:
> The Felix PPMC has voted on an incubator release and we would like to
> call an Incubator PMC vote to get final approval.
>
> We hope that this release represents the final step for Felix'
> graduation, but wish to pursue this official incubator release since we
> do not know how long graduation will take and feel it is important to
> make a public release available. We hope to request graduation once this
> incubator release is approved.
>
> The candidate incubator release can be found here:
>
> http://people.apache.org/~rickhall/felix-0.8.0-incubator.html
>
> We ask that you please vote to approve this release:
>
> [ ] +1 Approve the Felix 0.8.0-incubator release.
> [ ] -1 Veto the release (please provide specific comments)
>
> Thanks in advance for your effort in examining the release.
>
> - The Felix Team
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org