Re: [Infrastructure] Moving to myfaces - JIRA
The key cannot be renamed.. Mvgr, Martin Matthias Wessendorf wrote: FYI https://issues.apache.org/jira/browse/INFRA-1224 -Matthias
Re: [Infrastructure] Moving to myfaces
Your impression is kind of correct... (see http://www.apache.org/dev/reporting-issues.html) Which states that the private list needs to be cc'ed, the problem with JIRA is that it is not a mail , so it's hard to cc the private list.. You can trigger response in a couple of ways : 1) add threads to the issue pointing to the decision being made (although you move the work to the infrastructure team to investigate if the request is legit) or 2) Ask the chair to confirm the request in Jira 3) Let the PMC Chair make the request. On a couple of occasions I had to confirm an infra request to spark action. Mvgr, Martin Mike Kienenberger wrote: I agree that it would be good to run the details by the entire MyFaces PMC. However, my (possibly incorrect) understanding is that the PMC chair does not need to be the one making the request or giving the final ok -- it should be a PMC decision (or lazy concensus) and any PMC member can make the request. Matthias is a member of the MyFaces PMC. If I'm wrong, please stop me before I misinform again! :-) On 4/28/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Have Manfred give his ok to this.. Infrastructure requests need to come from the PMC.. Mvgr, Martin Matthias Wessendorf wrote: FYI https://issues.apache.org/jira/browse/INFRA-1223 Question, what's with John Fallows ? Greetings, Matthias
Re: [Infrastructure] Moving to myfaces - JIRA
Moving all tickets seems the best I think (you can do a mass update). Maybe infra has a nice trick for a key change and if so, I am very interested ;) Can we do this at Apachecon ? I am jira admin and can help out.. Mvgr, Martin Matthias Wessendorf wrote: :-( We need a new jira, and an export. something like that possible ? Or, we create a new, empty jira, and I can move all tickets. -Matthias On 4/28/07, Martin van den Bemt [EMAIL PROTECTED] wrote: The key cannot be renamed.. Mvgr, Martin Matthias Wessendorf wrote: FYI https://issues.apache.org/jira/browse/INFRA-1224 -Matthias
Re: VOTE graduation (was Re: Next steps? (was Re: Is trinidad ready for graduation ?))
+1 to start graduating :) Mvgr, Martin Matthias Wessendorf wrote: Hello Trinidad PPMC members and Trinidad community, [X] graduate as a TLP
Re: Next steps? (was Re: Is trinidad ready for graduation ?)
And a jakarta-style JSF components project. Let's assume we start the myfaces commons stuff in the near future, this JSF components TLP could have the following subprojects: -Tomahawk -Tobago -Trinidad -commons (non-renderkit-goodies) Martin, you are the man that know best about Jakarta, what are your thoughts on that? I won't bore you with the details that don't matter in this discussion and I won't state here that I know best, just because I am VP of Jakarta. First of all : - Jakarta is very big with about 109 projects and almost everyone at the ASF is committer, yes even you Matthias. - Jakarta has big PMC. In our scenario committers are not automatically on the PMC (there are projects doing that). Besides the benefits of being on the PMC (legal protection, binding votes on release, etc) you also have the obligation to give oversight to the project you are on the PMC for. Let's sketch a MyFaces scenario, with me as a potential committer. - I send a lot of patches for Trinidad - You get sick and tired of me and start a committer vote, so I can start applying patches myself. - I am a committer on the MyFaces TLP now. Even though I don't care about the JSF impl, I am committer there (ignoring svn karma rules that may have been set up) - If I end up on the PMC I am only interested in representing Trinidad (in fact I am just a Trinidad committer), so in fact I am not representing and giving oversight to the complete MyFaces TLP project. - The disconnect has happened between oversight and what is happening in the project. - Multiply above by many times and also don't assume people end up on the PMC and add a highly moving community to the mix (which means, important people become inactive and some new blood enters. - If a lot of old timers become inactive without looking for replacements and keeping the PMC in a good size, projects are going to have a hard time, new people don't have a possibility to make new releases (not enough votes) or don't know how to properly create releases, etc ,etc Not saying this is going to happen to MyFaces, just a scenario that is at Jakarta and also happens at smaller projects. So any symptoms of that are going to emerge at MyFaces, my advice is to fix the situation with going TLP for that subproject or making the PMC healthy again. Another problem with umbrella projects is that the board is not aware of any problems, dead code, etc, unless the chair or community writes that in the board report. So in fact you are (unintentionally) hiding possible problems. Hence the huge size of most Jakarta board reports to prevent hiding. Mvgr, Martin
Re: Next steps? (was Re: Is trinidad ready for graduation ?)
+1.. Thing to decide now is TLP or as subproject of MyFaces. Main thing is focus to decide on what to do : - People on MyFaces equally care about and work on Trinidad - People on Trinidad equally care about MyFaces MyFaces == the code base, not the TLP project. People working on Trinidad wouldn't necessarily be interested in working on the MyFaces code base. Giving oversight in an umbrella project will get harder and harder over time, which in the end does end up in a fragmented PMC. Which means that people on the PMC just have focus on eg MyFaces, tomahawk, Tobago or Trinidad. If you are a on the PMC you should care about all of these subprojects. In short : I favor TLP. Mvgr, Martin Matthias Wessendorf wrote: on our march reports, Jukka was asking: snip Things to do before graduation? /snip checking the checklist (briefly) it looks like we are set ... -M On 3/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 3/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hello Martin, your email states that this group should at least manage to get the release of the plugins out. I did. Currently this group is waiting for an approval to release the CORE as well. was approved and already released :-) One item, we need to check is Project ready to comply with ASF mirroring guidlines I will look at MyFaces, how we do it there, shouldn't be that big deal. posted to /www/people.apache.org/dis/incubator, as suggested here @GUMP: we use(d) continuum (was reseted currently) that should be ok?! What is your current thinking about this group? Start a vote? Fix the missing items? Wait for approval for CORE ? So, what is the next step ? A vote here on this list ? I think, we also need to run a vote on the MyFaces PMC, to accept Trinidad as one of their subprojects. I'll do that vote as well, when time comes ;-) -Matthias Thanks! Matthias On 2/10/07, Martin van den Bemt [EMAIL PROTECTED] wrote: In short : according to me they are.. Any feedback and additions appreciated.. On note : I like to see that at least the plugins get a release before we start a vote on dev (and I expressed below that you are targetting to have a release of core before leaving the incubator, although that could be a misunderstanding) If everyone agrees on dev, we start a vote on the incubator general list and after that on the MyFaces private list. Exit strategy probably needs to be discussed with the MyFaces crowd (like mailinglists) and they probably need to have votes on people on the trinidad ppmc list that are not yet on the MyFaces PMC (but that's up to the MyFaces PMC). I'll subscribe to the private myfaces list (in case you didn't know : I can as a member, which doesn't actually mean that I am on that PMC or have a binding vote there). The very long version : To determine if Trinidad is ready to leave the incubator I took http://incubator.apache.org/incubation/Incubation_Policy.html#Exiting+the+Incubator and tried to answer all the questions. The first 3 on that page are actually the last ones, since I am treating them more as general conclusions. Legal * All code ASL'ed Looking at https://issues.apache.org/jira/browse/ADFFACES-355 it is solved. Most important is that before the release everything is ok, so that check needs to be done before a release (eg by using RAT, mojo.codehaus.org is working on a maven2 plugin atm). * No non ASL or ASL compatbile dependencies in the code base Don't see any problems here (just checked the deps in the poms). * License grant complete Yep * CLAs on file. Yep. Even people who submitted patches were asked to file a CLA. * Check of project name for trademark issues Was tried, but since no one as access to the trademark database, it has hard to determine. Meritocracy / Community * Demonstrate an active and diverse development community The community is very active, people send in patches that get applied, user community is a bit behind, but that should grow ones Trinidad is released. * The project is not highly dependent on any single contributor (there's at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project) The main contributors are all employed by Oracle (based on the *commits* since end of December). These are matzew, jwaldman and awiner. gcrawford - Oracle jfallows- Not oracle anymore mmarinschek - Irian (?) slessard- DMR Consulting Inc (?) baranda - ? Mentors / champions craigmcc- Sun mvdb- Ordina (I don't count myself as a committer though) mgeiler - ? (not oracle afaik) Looking at the above list, it could mean a worry, which will be a lot less worry looking at the rest of the exit list
Re: Next steps? (was Re: Is trinidad ready for graduation ?)
Just a disclaimer : this is not an attack on you personally or a statement the the MyFaces Project is broken, just like to prevent that it becomes broken :) Mike Kienenberger wrote: I'm in favor of MyFaces for Trinidad. I would like to see Trinidad as the basis for Tomahawk JSF 1.2. So in this sense you are saying that we just incubated Tomahawk for JSF 1.2 ? When Trinidad becomes TLP it is for them to decide if they want that to happen (based on your proposal), if they go to the MyFaces TLP, it is not just their call. Which in the end (you gave an example of that) will end up in not a decision being made at all. If you think the Tomahawk developers / community have more in common than with the MyFaces developers, you should probably join Trinidad ;). Not the other way around.. However, if there is no interest in merging Tomahawk and Trinidad, then going with a TLP would be better. Even if there is interest, a TLP would not prevent a merge of the two, unless Trinidad doesn't want to or the MyFaces PMC doesn't want to. If all Tomahawk developers would like to merge with Trinidad and Trinidad wants to and the MyFaces PMC doesn't, there are other issues :) Right now, Tobago is in the state you described below -- You're either using Tobago (and no other component set), or you're using Tomahawk and other component sets. It's next to impossible to have oversight over both projects since Tobago is mutually-exclusive of other component sets. At one point, the Tobago people were interested in making Tobago more compatible with Tomahawk and other component sets, but discussion on how that would happen ever materialized beyond my initial questions. This is something that needs to be solved at MyFaces. If you wait too long, it cannot be fixed anymore (eg no one left to care about Tobago). Mvgr, Martin
Re: [RESULT] (was Re: [VOTE] [RETRY] approve the release of Trinidad's Core (1.0.0-incubating))
Incubator releases are destined for /www/people.apache.org/dist/incubator Mvgr, Martin Matthias Wessendorf wrote: Hey Martin, should we mirror the distribution of Trinidad and its examples? I haven't followed the discussion on [EMAIL PROTECTED] regarding how to tread incubating releases. Personally, I am fine in not! mirror them. Same with publishing them to ibiblio. Reason: Incubation is all about committed users... The JARS for maven, I'll deploy at the incubator repo. On 3/25/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: the release of trinidad core was approved, I'll follow up with the *need* procedure to *publish* the release. -M -- Forwarded message -- From: Matthias Wessendorf [EMAIL PROTECTED] Date: Mar 24, 2007 8:10 PM Subject: [RESULT] (was Re: [VOTE] [RETRY] approve the release of Trinidad's Core (1.0.0-incubating)) To: general@incubator.apache.org The votes of Trinidad's Core (1.0.0-incubating) release have been tallied: +1 Robert Burrell Donkin (Incubator PMC, binding) +1 Carsten Ziegeler (Incubator PMC, binding) +1 Martin van den Bemt (Mentor and Incubator PMC, binding) There were 3 binding Incubator PMC +1 votes and no 0 or -1 votes. I will follow up this email with an official release announcement. Thanks, Matthias On 3/24/07, Martin van den Bemt [EMAIL PROTECTED] wrote: +1... Mvgr, Martin Matthias Wessendorf wrote: Dear Incubator PMC Several issues were found by Robert, with the previous release files and have been resolved: 1.) bad signatures for trinidad-api-1.0.0-incubating.jar and trinidad-impl-1.0.0-incubating.jar - Resolution: Update to newer GPG Maven Plugin. A verify looks good: gpg: Signature made Wed Mar 21 07:21:31 2007 WEST using DSA key ID C2062385 gpg: Good signature from Matthias Wessendorf [EMAIL PROTECTED] 2.) missing signature for trinidad-api-1.0.0-incubating-tests.jar and trinidad-impl-1.0.0-incubating-tests.jar - Resolution: Update to newer versions of GPG Maven Plugin. A verify looks good, too. 3.) missing LICENSE, NOTICE and DISCLAIMER in the following files: *trinidad-api-1.0.0-incubating-javadoc.jar *trinidad-api-1.0.0-incubating-tests.jar *trinidad-impl-1.0.0-incubating-javadoc.jar *trinidad-impl-1.0.0-incubating-tests.jar - Resolution: Update to newer version of Remote-Resource-Plugin. 4.) trinidad-1.0.0-incubating-example.zip is missing DISCLAIMER - Resolution: added missing file, to be included by the assembly 5.) Missing license header in: http://svn.apache.org/repos/asf/incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/config/upload/UploadRequestWrapper.java - Resolution: added missing header 6.) In the trindad-impl-1.0.0-incubating-sources RAT reveals that there are lots of javascript files in META-INF/adf/jsLibs/ and some configuration files in META-INF without headers. are these generated? -Answer: Yes, some are generated and some are obfuscated, during build. The whole point of obfuscating is to eliminate unnecessary content in our downloads. (when sending the JavaScript files to the client/browser). -- New versions of the release files can be found at: http://people.apache.org/~matzew/stage_trin_core/(maven2 staging repo) http://people.apache.org/~matzew/dist_trin_core/ (the distribution) Please cast your votes: [ ] +1 Release is approved [ ] -1 Veto the release (provide specific comments) Thanks, Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [vote] release of core (1.0.0-incubating)
+1 :) Mvgr, Martin Matthias Wessendorf wrote: Hey Martin, I just did an upload of those checksum files to: http://people.apache.org/~matzew/dist_trin_core/ so, now I would count your vote as a +1 The other thing (commons-logging), I'd like to check for the next release, ok? Thx, Matthias On 3/14/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 3/14/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Sorry people for the late response.. -1.. Missing md5/sha1 checkum for tar.gz and zip (the dist_trin_core). If they are added and are ok, I am changing to +1.. haha! you got me :-) Thanks! Maybe wise to add a text that the binary dist is a complete distribution including sources (most of the time you see a separate release for source). No issues here with it all being in one dist though yes, I used the pattern from Tobago, so I followed it ;) Also I rather see incubating-example unpack in it's own directory (no blocker btw, just personal preference, since it messes up my unpacked dist package). Another question : Why is commons-logging version 1.0 included and not a later version ? well,... lemme check, perhaps dependency of a dependency ? :) I'll fix the md5/sha1 thing tomorrow and upload a new dist. -Matthias Mvgr, Martin Matthias Wessendorf wrote: Hi, I managed to get some release artifacts published to a stage repo. I used my private Apache account for that ([1]). Also there is a distribution available at [2]. Please take a look at the 1.0.0-incubating artifacts and vote if we should take these file to ask the Incubator PMC for approval [ ] +1 (Binding) for PPMC members only [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Matthias [1] http://people.apache.org/~matzew/stage_trin_core/ [2] http://people.apache.org/~matzew/dist_trin_core/ -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Volunteers for the Incubator board report ?
I am not volunteering, but it is board report time again... Mvgr, Martin
Re: [vote] release of plugins (1.0.0-incubating)
It seems like a precondition in this thread : your name must start with the letters ma :) Hmm missing the vote of the other Martin ;) Oh something useful : also add the names of the people who voted in the vote result, so people on general know who voted (and use the contents of the vote result as the basis of the vote mail on general) Mvgr, Martin Martin van den Bemt wrote: The javadoc things sucks.. We probably can get it work (to add notice, etc), but at a high cost I think (at least I couldn't get the simplest solution working, which is adding files to src/main/javadoc) (another note : for once I didn't look at the sourcecode how stuff works). So from me +1 (I didn't check every single artifact, just a snapshot) of what was in the staging environment. And about the vote : you have to start it on general :) Just do a VOTE RESULT first here (specify who voted, if the person is on the PPMC or/and on the Incubator PMC (and also result the votes of people who don't have a binding vote (since they are worth something). If Craig also casts his vote and one other person (like Robert) we can really release this baby and start with releasing the core :) Yeeha :) Mvgr, Martin Matthias Wessendorf wrote: btw. the javadoc jar issue is triggered by a bug inside of the plugin. Martin, do you bring the vote up to [EMAIL PROTECTED], once you voted +1 :) Thanks, Matthias On 2/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Ok, Martin I fixed those things http://people.apache.org/~matzew/stage/ Once we get the approval from the Incubator PMC guys, I'd like to test/use this tool for doing the copy: http://docs.codehaus.org/display/MAVENUSER/Repository+Tools -Matthias On 2/19/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Sorry for the delay (board report time).. - Source jar contains target directory (probably need to do an exclude of that specifically) - Source jar src/site don't contain licenses - Javadoc jar don't contain any notices and license (since javadoc is generated the html doesn't need apache headers) Not blocking : In the MANIFEST.MF file I am missing the version of the plugin (for the trinidad core a lot more important) and also the build version is 1.5. Don't know if that is the target / needed ? (afaik trinidad core is 1.5) If you fix the source and javadoc I am +1 :) Sorry for the tough crowd. On the other hand : if you get it right once, you should be able to get it right everywhere :) Mvgr, Martin Matthias Wessendorf wrote: Hi, I finally managed to get some release artifacts published to a stage repo. I used my private Apache account for that ([1]). Please take a look at the 1.0.0-incubating artifacts and vote if we should take these file to ask the Incubator PMC for approval [ ] +1 (Binding) for PPMC members only [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Matthias [1] http://people.apache.org/~matzew/stage/ -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [vote] release of plugins (1.0.0-incubating)
Sources and javadoc probably don't reuse that information and to be honest I
don't know how well the
source-plugin and javadoc-plugin is configurable with this (have to dig into
this)
Mvgr,
Martin
Matthias Wessendorf wrote:
Thanks for your feedback.
I will add the src/site thing. But in the meantime, I have these question:
Why is the source-plugin adding the target/ ?
Why is this:
build
resources
resource
directorysrc/main/resources/directory
/resource
!-- also include license and notice files in all the jars --
resource
directory${basedir}//directory
includes
includeNOTICE.txt/include
includeLICENSE.txt/include
includeINCUBATOR_NOTICE.txt/include
/includes
targetPathMETA-INF/targetPath
/resource
/resources
not applied to the javadoc/sources plugin ?
thx,
M
On 2/19/07, Martin van den Bemt [EMAIL PROTECTED] wrote:
Sorry for the delay (board report time)..
- Source jar contains target directory (probably need to do an exclude
of that specifically)
- Source jar src/site don't contain licenses
- Javadoc jar don't contain any notices and license (since javadoc is
generated the html doesn't
need apache headers)
Not blocking :
In the MANIFEST.MF file I am missing the version of the plugin (for
the trinidad core a lot more
important) and also the build version is 1.5. Don't know if that is
the target / needed ? (afaik
trinidad core is 1.5)
If you fix the source and javadoc I am +1 :)
Sorry for the tough crowd. On the other hand : if you get it right
once, you should be able to get
it right everywhere :)
Mvgr,
Martin
Matthias Wessendorf wrote:
Hi,
I finally managed to get some release artifacts published to a stage
repo. I used my private Apache account for that ([1]).
Please take a look at the 1.0.0-incubating artifacts and vote if we
should take these file to ask the Incubator PMC for approval
[ ] +1 (Binding) for PPMC members only
[ ] +1 for community members who have reviewed the bits
[ ] +0
[ ] -1 for fatal flaws that should cause these bits not to be released,
and why..
Thanks,
Matthias
[1] http://people.apache.org/~matzew/stage/
Re: [vote] release of plugins (1.0.0-incubating)
I don't mind having it in the the META-INF directory btw..
Mvgr,
Martin
Matthias Wessendorf wrote:
Hey Martin,
is there a need that we need to have the NOTICE, LICENSE and
INCUBATOR.TXT in $basedir} ?
When moving them to src/resource/meta-inf they are in the META-INF of
the -source jar and the *real* jar.
But still not inside the javadoc-JAR. Any idea ?
-M
On 2/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Thanks for your feedback.
I will add the src/site thing. But in the meantime, I have these
question:
Why is the source-plugin adding the target/ ?
Why is this:
build
resources
resource
directorysrc/main/resources/directory
/resource
!-- also include license and notice files in all the jars --
resource
directory${basedir}//directory
includes
includeNOTICE.txt/include
includeLICENSE.txt/include
includeINCUBATOR_NOTICE.txt/include
/includes
targetPathMETA-INF/targetPath
/resource
/resources
not applied to the javadoc/sources plugin ?
thx,
M
On 2/19/07, Martin van den Bemt [EMAIL PROTECTED] wrote:
Sorry for the delay (board report time)..
- Source jar contains target directory (probably need to do an
exclude of that specifically)
- Source jar src/site don't contain licenses
- Javadoc jar don't contain any notices and license (since javadoc
is generated the html doesn't
need apache headers)
Not blocking :
In the MANIFEST.MF file I am missing the version of the plugin (for
the trinidad core a lot more
important) and also the build version is 1.5. Don't know if that is
the target / needed ? (afaik
trinidad core is 1.5)
If you fix the source and javadoc I am +1 :)
Sorry for the tough crowd. On the other hand : if you get it right
once, you should be able to get
it right everywhere :)
Mvgr,
Martin
Matthias Wessendorf wrote:
Hi,
I finally managed to get some release artifacts published to a stage
repo. I used my private Apache account for that ([1]).
Please take a look at the 1.0.0-incubating artifacts and vote if we
should take these file to ask the Incubator PMC for approval
[ ] +1 (Binding) for PPMC members only
[ ] +1 for community members who have reviewed the bits
[ ] +0
[ ] -1 for fatal flaws that should cause these bits not to be
released,
and why..
Thanks,
Matthias
[1] http://people.apache.org/~matzew/stage/
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [vote] release of plugins (1.0.0-incubating)
Sorry for the delay (board report time).. - Source jar contains target directory (probably need to do an exclude of that specifically) - Source jar src/site don't contain licenses - Javadoc jar don't contain any notices and license (since javadoc is generated the html doesn't need apache headers) Not blocking : In the MANIFEST.MF file I am missing the version of the plugin (for the trinidad core a lot more important) and also the build version is 1.5. Don't know if that is the target / needed ? (afaik trinidad core is 1.5) If you fix the source and javadoc I am +1 :) Sorry for the tough crowd. On the other hand : if you get it right once, you should be able to get it right everywhere :) Mvgr, Martin Matthias Wessendorf wrote: Hi, I finally managed to get some release artifacts published to a stage repo. I used my private Apache account for that ([1]). Please take a look at the 1.0.0-incubating artifacts and vote if we should take these file to ask the Incubator PMC for approval [ ] +1 (Binding) for PPMC members only [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Matthias [1] http://people.apache.org/~matzew/stage/
Re: [vote] release of plugins (1.0.0-incubating)
Will look at this Saturday (which it already is, but it is actually bed time I think). I am behind on mail since Wednesday :( Mvgr, Martin Matthias Wessendorf wrote: Hi, I finally managed to get some release artifacts published to a stage repo. I used my private Apache account for that ([1]). Please take a look at the 1.0.0-incubating artifacts and vote if we should take these file to ask the Incubator PMC for approval [ ] +1 (Binding) for PPMC members only [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Matthias [1] http://people.apache.org/~matzew/stage/
Re: [release] fun with maven
I just stage to my home directory on people.. Mvgr, Martin Matthias Wessendorf wrote: There is no real staging repo! right .../people.apache.org/builds/myfaces/m2-staging-repository is nothing more than a temporary folder that is currently used for preparing the core 1.1.5 release. So please use a different staging dir for Trinidad to minimize the risk of unwanted affects on the current core release procedure. sure, I'll use a different dir for that, just to clear the maven thing first. Since there is no real staging repo, I was about to put the *release* to that (since it is not official). Doing a vote based on that, and asking the Incubator PMC for approval on the stuff in the staging repo. (Yes, I'll create a trinidad-stage-repo) I read your diary, but you are on a different *environment*. I am using profiles in the pom.xml etc. can you post your settings.xml ? Nothing special in my settings.xml. gpg-plugin workes fine without any settings. Does manual signing with gpg work fine on your machine? To sign works fine here. Ok, perhaps I just try to deploy the prepared stuff to something . since the -Psign-artifact seams to work w/o special things in settings or pom Thanks, --Manfred On 2/13/07, Manfred Geiler [EMAIL PROTECTED] wrote: Matze, First of all, please do not deploy tomahawk into .../people.apache.org/builds/myfaces/m2-staging-repository right now. We are currently preparing core 1.1.5 in this dir which will later be moved to .../people.apache.org/builds/myfaces/core-1.1.5/m2-staging-repository. Please create a new staging folder for tomahawk e.g. .../people.apache.org/builds/myfaces/tomahawk/m2-staging-repository Thanks! Specifiying the passphrase with -Dpassphrase=VALUE worked fine for me. See http://wiki.apache.org/myfaces/CoreRelease115#diary (Point 4, last step) BTW, you are doing a release:perform before the vote? Why that? --Manfred On 2/13/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, since I got some feedback here regarding how to move forward with the release, I was able to do this nice command (see also svn checkins, triggered by that tool): mvn release:prepare -Prelease,staging -Dpassphrase=myPhrase -Ddeploy.altRepository= scpexe://people.apache.org/www/people.apache.org/builds/myfaces/m2-staging-repository ok, that went through next try was mvn release:perform -Prelease,staging -Dpassphrase=myPhrase -Ddeploy.altRepository= scpexe://people.apache.org/www/people.apache.org/builds/myfaces/m2-staging-repository That presents me a nice error in this format. niceError [ERROR] BUILD ERROR [INFO] [INFO] One or more required plugin parameters are invalid/missing for 'gpg:sign' [0] inside the definition for plugin: 'maven-gpg-plugin'specify the following: configuration ... passphraseVALUE/passphrase /configuration -OR- on the command line, specify: '-Dpassphrase=VALUE' /niceError Fair enough, my friend needs a passphrase. Well I should add it to the pom or the command line. But that tool seems to ignore it... (see above) Does anyone know how to solve that ? Thanks, Matthias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [release] vote ??
We can do both, but I will focus on the binary.. Mvgr, Martin Matthias Wessendorf wrote: Hi, I was able to prepare the relase, based on the given feedback. Maven created already a TAG for that (see [1]). Should we vote on the tag (meaning source files) or on a binary artifact ? I think here, in the Trinidad DEV list we should vote on the source files. After that, when moving to [EMAIL PROTECTED], we should as them for approval, based on a binary release. Thanks for any kind of feedback. -Matthias [1] http://svn.apache.org/repos/asf/incubator/adffaces/tags/maven-plugin-parent-1.0.0-incubating/
Re: [release] vote ??
Btw this is not just an incubator requirement.. It's a requirement for all projects to vote on binaries.. Normally discussion about code is held in the are we ready for release vote, after that on binaries. Mvgr, Martin Matthias Wessendorf wrote: I think the process here is a bit different than in a real Apache project. We need to get approval from Incubator PMC on binaries that are exactly the same that we put into a real m2-repo. A podling can't simply put together a release. it needs an approval on some binaries and when that approval is there, the release process is ended. Runing the release:perform after asking the incubator PMC would change this (IMO) -M On 2/13/07, Manfred Geiler [EMAIL PROTECTED] wrote: No. release:perform ends the release process - after the vote! Just do a mvn clean deploy -Psign-artifacts (after you have checked that distributionManagement points to the correct staging dir) --Manfred On 2/13/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: so that means doing a release:perform to a staging repo (where ever that is) to continue ? -M On 2/13/07, Martin van den Bemt [EMAIL PROTECTED] wrote: We can do both, but I will focus on the binary.. Mvgr, Martin Matthias Wessendorf wrote: Hi, I was able to prepare the relase, based on the given feedback. Maven created already a TAG for that (see [1]). Should we vote on the tag (meaning source files) or on a binary artifact ? I think here, in the Trinidad DEV list we should vote on the source files. After that, when moving to [EMAIL PROTECTED], we should as them for approval, based on a binary release. Thanks for any kind of feedback. -Matthias [1] http://svn.apache.org/repos/asf/incubator/adffaces/tags/maven-plugin-parent-1.0.0-incubating/ -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Is trinidad ready for graduation ?
In short : according to me they are.. Any feedback and additions appreciated.. On note : I like to see that at least the plugins get a release before we start a vote on dev (and I expressed below that you are targetting to have a release of core before leaving the incubator, although that could be a misunderstanding) If everyone agrees on dev, we start a vote on the incubator general list and after that on the MyFaces private list. Exit strategy probably needs to be discussed with the MyFaces crowd (like mailinglists) and they probably need to have votes on people on the trinidad ppmc list that are not yet on the MyFaces PMC (but that's up to the MyFaces PMC). I'll subscribe to the private myfaces list (in case you didn't know : I can as a member, which doesn't actually mean that I am on that PMC or have a binding vote there). The very long version : To determine if Trinidad is ready to leave the incubator I took http://incubator.apache.org/incubation/Incubation_Policy.html#Exiting+the+Incubator and tried to answer all the questions. The first 3 on that page are actually the last ones, since I am treating them more as general conclusions. Legal * All code ASL'ed Looking at https://issues.apache.org/jira/browse/ADFFACES-355 it is solved. Most important is that before the release everything is ok, so that check needs to be done before a release (eg by using RAT, mojo.codehaus.org is working on a maven2 plugin atm). * No non ASL or ASL compatbile dependencies in the code base Don't see any problems here (just checked the deps in the poms). * License grant complete Yep * CLAs on file. Yep. Even people who submitted patches were asked to file a CLA. * Check of project name for trademark issues Was tried, but since no one as access to the trademark database, it has hard to determine. Meritocracy / Community * Demonstrate an active and diverse development community The community is very active, people send in patches that get applied, user community is a bit behind, but that should grow ones Trinidad is released. * The project is not highly dependent on any single contributor (there's at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project) The main contributors are all employed by Oracle (based on the *commits* since end of December). These are matzew, jwaldman and awiner. gcrawford - Oracle jfallows- Not oracle anymore mmarinschek - Irian (?) slessard- DMR Consulting Inc (?) baranda - ? Mentors / champions craigmcc- Sun mvdb- Ordina (I don't count myself as a committer though) mgeiler - ? (not oracle afaik) Looking at the above list, it could mean a worry, which will be a lot less worry looking at the rest of the exit list. * The above implies that new committers are admitted according to ASF practices Absolutely. There were 3 committers added during incubation, one not Oracle and 2 Oracle people. From my perspective all 3 deserved to be committer (with that amount of activity, people should be voted in as a committer to be honest), so no favours were made just because someone is from Oracle. Currently some other people are on the radar to become committer (non Oracle). * ASF style voting has been adopted and is standard practice In every way. * Demonstrate ability to tolerate and resolve conflict within the community. Haven't noted much conflicts to be honest, but I am happy with the oversight that is done and how commits that get feedback get resolved quickly. I use the word feedback, since I haven't noticed any strong -1 on a commit, since there is respect for each others knowledge, ego's don't tend to play up, which is a good thing. * Release plans are developed and excuted in public by the community. This is done and currently the project is making it easier to do release (cut down the manual work of the release). The project has some problems getting a release out the door, which is partially solved by adding another mentor, so the project actually can get 3 binding votes on a release. The goal is to release the plugins and the core before leaving incubation. Currently there is http://wiki.apache.org/myfaces/TrinidadReleaseProcedure on the wiki, which after the releases are done can be formalised as a permanent part of the website. * Engagement by the incubated community with the other ASF communities, particularly infrastructure@ (this reflects my personal bias that projects should pay an nfrastructure tax). This is the case, since there is my synergy with the MyFaces community and most people from Trinidad are also actively involved there. So infrastructure is less of a problem, since that is handled (in the future) by the MyFaces PMC. * Incubator PMC has voted for graduation * Destination PMC, or ASF Board for a TLP, has voted for final acceptance The goal of this mail to get those votes :) Alignment / Synergy * Use of other ASF
Re: When's Trinidad/ADFFaces graduation?
For graduation votes the following needs to happen : - Vote on this list for graduation - Vote on incubator general - The MyFaces PMC needs to vote to accept Trinidad (or the board if trinidad goes TLP) Before we start a vote however, I would still want to walk through this checklist http://incubator.apache.org/incubation/Incubation_Policy.html#Exiting+the+Incubator. Please don't start answering all things above yet, since it is something I want to figure out, since people on the incubator PMC would probably do the same and it's better that we hit the problem areas than when the vote on general happens. I will try to get the mail out to the dev in the coming week. Mvgr, Martin Matthias Wessendorf wrote: Hi Mike, see some comments inline. On 2/4/07, Mike Kienenberger [EMAIL PROTECTED] wrote: Speaking of incubator issues, what's holding up graduation of Trinidad at this point? From what I've seen, the community is active and understands the Apache way. I agree The status page appears to have checked off all of the outstanding tasks. The only relevent thing in the last board report (which is missing from the status page, by the way) was cleanup of notices and licenses for compliance with the ASF and there's no indication that any further incubating tasks are pending. http://wiki.apache.org/incubator/December2006 I overhauled the source files to met compliance w/ the ASF during the last month. all JARs now also contain the NOTICE.TXT and LICENSE.TXT As far as I know, the only thing that might be holding up graduation is a dry-run through a release, and that doesn't have to wait until there's a real release ready. Martin van den Bemt (our mentor) and me are working on that. I am fighting with a maven profile (see my next email) I'd be +1 on accepting Trinidad under MyFaces at this point. I am definitely +1 on that as well. (binding like yours from MyFaces PMC standpoint) How did you guys handle that with Cayenne ? Did you guys voted in your dev list on that?`Or just *asking* for graduation on the [EMAIL PROTECTED] list ? -Matthias
Name change..
There isn't any notice on the name change on the status page. I assume that the name change is there to stay ? Would also be nice if someone still has some idea on what date the name change actually happened. Since the rest is still called adffaces (list names, incubator page, etc) I am not sure if we need to change those names to trinidad before graduation Thoughts ? We can also bring this discussion to general to ask for opinions, although I think the overhead created with changing the name in every area isn't probably worth it. (assuming Oracle still is ok that the name ADF Faces is used?) Mvgr, Martin
Re: Name change..
Martin van den Bemt wrote: We can also bring this discussion to general to ask for opinions, although I think the overhead created with changing the name in every area isn't probably worth it. () That sentence should read assuming Oracle still is ok that the name ADF Faces is used during incubation.. Mvgr, Martin
Re: Name change..
We'll leave it as is and I will update the status page, since according to the status page the name change is still unresolved.. (i'll look at the incubator report to see when this exactly happened) Mvgr, Martin Adam Winer wrote: On 2/3/07, Martin van den Bemt [EMAIL PROTECTED] wrote: There isn't any notice on the name change on the status page. I assume that the name change is there to stay ? Would also be nice if someone still has some idea on what date the name change actually happened. Since the rest is still called adffaces (list names, incubator page, etc) I am not sure if we need to change those names to trinidad before graduation When we graduate, we'll just be on the myfaces list, at least to start. It wasn't clear to me that it'd be worth the effort of getting new mailing lists, asking everyone subscribed to move over, etc., just to discard that mailing list once we're out. Thoughts ? We can also bring this discussion to general to ask for opinions, although I think the overhead created with changing the name in every area isn't probably worth it. (assuming Oracle still is ok that the name ADF Faces is used?) No problems as far as I know. -- Adam (@ Oracle corp.)
Re: Plugins release..
To make things clear : The showstoppers or on the release vote thread and this mail should be separate, they are just things to make life easier (at least that was my intention). About the mentor part : If you think I am not listening in, you could (for safety) ping my apache address, although I must add that being a mentor is doing more than vote on the incubator general list (the preferred way is that the mentors already have voted before you move the vote to general). I will start improving on my mentorship by reading the list on regular basis, instead of irregular basis :) Pinging me when something important happens isn't a bad idea though in case I get swamped with Jakarta issues (which requires a lot of reading) Mvgr, Martin Matthias Wessendorf wrote: Hello Martin, thanks for valuable feedback, appreciate that. See inline for some comments On 1/16/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Hi people, Just was checking the plugins release and I noticed a couple of things that could be improved (this is not specifically about the release, but more technical). A couple of things were missing from the release, which could be handled a different way : - The parent pom of trinidad plugins could org.apache/apache/3 (think that is ) This fixes the license things automatically. done, uploading the new homepage later today - if you put a NOTICE.txt and LICENSE.txt in every root of an artifact (plugins can be used individually, so I think they need to be there anyway), you can simply use the resources plugin to include them from the root of the plugin, instead of having them in src/main/resources. In any case, the NOTICE could be different for every plugin (eg could imagine adding javacc to the notice of the javacc plugin) I used resources plugin to archive that; for javacc I added Sun's BSD-style license to our license txt as well; also I added a comment to the notice.txt file the incubator_notice.txt is now also part of meta-inf folder. - The current signing of the plugin (when doing releases) is uncommented. You can also put that in a profile, so you don't have to change the pom each time (probably could also be done in a profiles.xml, but to be honest, I never used that) is that really a show stopper ? other podlings aren't doing this as well; currently it is only me doing the release or trying to (only my gpg-key part of KEYS file) - Add some documentation how a release are made by the trinidad project (also for the non plugin releases). (if it is already there, sorry didn't look too close :) what do you mean? We have a wiki page, containing some infos on the release (fixed issues etc) If I can find some time I can do some of the changes myself and send patches / commit myself (whatever is preferred, in the commit myself scenario I will give myself karma for trinidad). I can also do it in a branch, so you can review if you are happy with the changes I have in mind.. Go ahead and yourself karma for trinidad. Also I don't mind if you work on my matzew-m1-plugins branch. As mentioned, I already addressed lot's of the issues One more thing from my side to you as a mentor: I already did a vote thread here in trinidad, should I do a CC to your private email address to ensure that a vote like this is on your radar ? ;) Thanks again for taking the time to help/guide us. mfg, Matthias Mvgr, Maritn
Plugins release..
Hi people, Just was checking the plugins release and I noticed a couple of things that could be improved (this is not specifically about the release, but more technical). A couple of things were missing from the release, which could be handled a different way : - The parent pom of trinidad plugins could org.apache/apache/3 (think that is ) This fixes the license things automatically. - if you put a NOTICE.txt and LICENSE.txt in every root of an artifact (plugins can be used individually, so I think they need to be there anyway), you can simply use the resources plugin to include them from the root of the plugin, instead of having them in src/main/resources. In any case, the NOTICE could be different for every plugin (eg could imagine adding javacc to the notice of the javacc plugin) - The current signing of the plugin (when doing releases) is uncommented. You can also put that in a profile, so you don't have to change the pom each time (probably could also be done in a profiles.xml, but to be honest, I never used that) - Add some documentation how a release are made by the trinidad project (also for the non plugin releases). (if it is already there, sorry didn't look too close :) If I can find some time I can do some of the changes myself and send patches / commit myself (whatever is preferred, in the commit myself scenario I will give myself karma for trinidad). I can also do it in a branch, so you can review if you are happy with the changes I have in mind.. Mvgr, Maritn
