Com'on guys calm down.. @Oleg: Please just start your work on trunk or a branch inside apache. This way we will still be able to see your commits as notifications etc. I don't see why you want to take the code to github. Just work here..
Bye, Norman 2011/1/11 Stefano Bagnara <[email protected]>: > 2011/1/11 Oleg Kalnichevski <[email protected]>: >> On Tue, 2011-01-11 at 15:18 +0100, Stefano Bagnara wrote: >>> 2011/1/11 Oleg Kalnichevski <[email protected]>: >>> > On Tue, 2011-01-11 at 14:01 +0100, Stefano Bagnara wrote: >>> >> 2011/1/11 Oleg Kalnichevski <[email protected]>: >>> >> > On Tue, 2011-01-11 at 09:27 +0100, Norman Maurer wrote: >>> >> >> Hi there, >>> >> >> >>> >> >> I think if it worth it we should release 0.6.2. Release often release >>> >> >> early, you know ;) >>> >> >> >>> >> >> Bye, >>> >> >> Norman >>> >> >> >>> >> > >>> >> > Folks >>> >> > >>> >> > I also would like to port another fix, should we decide to do another >>> >> > release off the 0.6.x branch. >>> >> >>> >> What is the other fix? This one is not critical (I see it just like a >>> >> documentation bug: either way we need that check on that field to work >>> >> that way, we can't simply check the line length). >>> >> >>> > >>> > Parsing of folded fields. The default field parser in 0.6 chokes on >>> > perfectly valid fields if their body is folded. >>> > >>> > >>> >> > I am also willing to make a push toward the 0.7 release, if no one is >>> >> > going to pick up work on the API changes stared by Stefano on the >>> >> > trunk. >>> >> >>> >> I had really few time but I think I also slowed down because I never >>> >> understood if what I was doing was liked or not. It takes a lot to >>> >> complete stuff, so I would have liked to understand what others thinks >>> >> we should do in 0.7. >>> >> >>> >> As an example I see sometimes we talk as 0.x versions we can do >>> >> backward incompatible changes trying to reach a good api, other times >>> >> it seems we instead are "stuck" to the 0.6 version because 0.6 has >>> >> already a lot of users so compatibility is brought to the table. >>> >> >>> >> That said, I say my opinion and I expect others to say their opinions >>> >> so that we can see where we can find a consensus. >>> >> - I think 0.6 is not "great" as API, so I would happily break >>> >> compatibility in order to provide a better api. Main thing is that the >>> >> 0.6 API does not accept evolution (every non trivial feature will >>> >> require a backward incompatible change). >>> >> - IMO current trunk could be released as 0.7.0 with very minor change: >>> >> it is far from exposing a complete api, but I find it already better >>> >> than 0.6 and I have already some product depending on current trunk. >>> >> We saw we proceed at a slow speed, so we should be prepared improving >>> >> the API while we reach 1.0. >>> >> - I guess most of changes we have in trunk are not backportable to 0.6 >>> >> because they have been possible by the major refactorings, but I'm not >>> >> against this, if anyone sees a way. >>> >> >>> >> Can you state yours and also tell something more about "your" 0.7 plan? >>> >> >>> > >>> > I think we discussed this on more than one occasion in the past. While I >>> > think mime4j 'core' in 0.7 is fine, the 'dom' / 'message' stuff is not, >>> >>> Yes, we discussed a couple of times, but we didn't find a solution (at >>> least not one I understood) >>> >>> > and the whole library is not in a releasable state at the moment. >>> >>> Got it: hope you will review trunk soon to understand what changes you >>> propose to make it releasable. >>> >>> > And there is "my" plan: >>> > >>> > (1) ask people to go over issues in JIRA and decide what is in scope for >>> > 0.7 and what can wait until a better day (0.8) >>> >>> +1 >>> >>> The main causes I use trunk in production instead of 0.6 are: >>> MIME4J-158 - Reduce usage of commons-logging in favor of a "Monitor" >>> service. >>> https://issues.apache.org/jira/browse/MIME4J-158 >>> MIME4J-58 - Lenient dealing with headless messages or malformed >>> header/body separation >>> https://issues.apache.org/jira/browse/MIME4J-58 >>> MIME4J-153 - Headless inconsistency between MimeTokenStream and >>> MimeStreamParser >>> https://issues.apache.org/jira/browse/MIME4J-153 >>> >>> Also the folded header stuff you mentioned (MIME4J-141 - MIME4J-146) >>> >>> > (2) revisit the 'dom' and 'message' packages and try to figure out >>> > whether 'model' and 'implementation' classes in their present form make >>> > sense. >>> >>> +1 >>> >>> > In my option, many of them do not. >>> >>> They are the result of my limited use case: they work fine in my use >>> cases (jDKIM + proprietary product). >>> We need more real use cases to "shape" them, but I trust you (and you >>> probably have good uses cases too), so I will wait for your review. >>> >>> Stefano >>> >> >> Stefano, for the love of God Almighty, what else am I supposed to do? > > I don't get what I said to upset you. I'm sorry if you thought I'm on > the way. I keep repeating you just commit your changes, just do > whatever you want on svn and I will be happy. You don't commit > anything so I try discussing. I don't know what you prefer me to do. > I'm just trying to understand how to evolve mime4j. > >> I >> pointed out a number of times those things that do not seem to make any >> sense what so ever, like HeaderImpl extending Header, which is a >> CONCRETE class, or abstract Multipart where the only abstract aspects >> are preamble / epilogue related methods. >> >> OK. I will create a copy of mime4j on github and make _minimal_ changes >> to your code just to resolve the most glaring WTFs in the API and >> present it for review. Simply listing things that I disagree with does >> not seem to bring us anywhere anymore. > > Why can't you simply work on trunk or on a branch here in our svn? I > think I encouraged you multiple times to simply do this, I don't > really understand why you aswer me like I'm trying to stop you. > My preference is for you to use trunk. We use CTR, so go ahead and I > hope you will be happy if I review what you do. > > You are a committer, so we already trust you, so you should no fear > working in trunk. I do this when I have ideas and I expect others to > simply do the same. If what I committed in trunk is blocking evolution > then just revert it, otherwise make your changes: whatever you feel > appropriate. > > We will ask questions when we need answers :-) > > Stefano > > PS: if something I said/did makes you angry just explain me please. I > hope this is just something related to "translation" and the fact we > don't speak the same language natively. >
