I have no problem whatsoever with you. Possibly since you have so much to say about the project, much more than any other PMC chair I’ve encountered, you run into my concerns more often.
I have several motivations. Back when I was first involved in an Apache project, around 2004, the board stepped in because they thought we weren’t following apache policies. They could well have been correct, but the oversight was not pleasant. I might be hypervigilant, but I really really don’t want that to happen to Camel. I also follow the incubator list and have some idea what new projects are expected to do. When I see something that looks to me like it’s inconsistent with a policy or likely to provoke a correction if Camel were in the incubator, I try to ask what’s going on. I’ve also found that at least for me having behavior consistent across projects is much more welcoming to new contributors than having unusual practices. Even though I’m a founding PMC member of Camel, I’ve only started contributing quite recently when I realized I might be able to help with the website. I definitely feel like a newcomer. When I find something that seems confusing or unwelcoming, I try to ask about it: I suspect that if I find it unwelcoming others might also. Finally, camel is pretty complex, and there are a lot of subprojects, and I haven’t found documentation about how they are related. I’ve been slowly trying to understand how they are related and find ways to make the documentation reflect that more clearly. Sometimes I get confused, can’t find the right place to look, or don’t look far enough, and ask…. perhaps not always very politely. However, I’ve always already spent some time investigating and am genuinely puzzled before I ask. Let’s look at an example… It’s an absolute policy that projects make it really clear that non-released code is only for project development purposes. I don’t know to what extent this is a firm policy for websites, and I’ve never seen it discussed, perhaps because AFAIK no other projects have a multi-version website capable of showing the docs for unreleased versions under development, but I think it’s pretty obvious that having the default view be of a released version is more consistent with this policy that having the default be an unreleased dev version. I also think it’s much more friendly to users to have the docs by default show you something it’s appropriate for you to use. After several steps, I think the website is now by default showing the docs for the latest released version of every subproject rather than the unreleased dev version, and it displays some indication that you shouldn’t be using the unreleased version. My recollection of the history here is… - I noticed that the default was “latest” which was unreleased, and thought that wasn’t very consistent with the “direct people to released code only” policy, especially since there was no clear indication that the docs referred to something unreleased. It was pretty easy to use Antora facilities to mark it prerelease and to have the display version show “prerelease” so at least there’s some indication of the status and Antora would regard the latest released version as “latest" - Eventually I realized we could use redirects to get the hugo portion of the site to point by default to released versions. - I noticed there was no released version of kamelets in the docs and tried to find out why…. should no one be using kamelets???… there’s no documentation that they have ever been released!!! I wasn’t very successful at deciphering the rather inconsistent state of the website or finding the vote emails, and asked, perhaps with a bit too much panic. I think we’ve mostly straightened this out now. Thanks David Jencks > On Dec 19, 2021, at 11:33 AM, Andrea Cosentino <anco...@gmail.com> wrote: > > It looks to me you have something personal with me, because each time I > write something you suddenly appear and ask why, reporting rules.. what is > exactly your problem with me? > > Il dom 19 dic 2021, 20:26 Andrea Cosentino <anco...@gmail.com> ha scritto: > >> And btw i know the ASF rules better than you. To me 72 hours doesn't make >> any sense and I'm trying to use my brain instead of reporting a well known >> rule. >> >> Il dom 19 dic 2021, 20:23 Andrea Cosentino <anco...@gmail.com> ha scritto: >> >>> For any other problem you can write to the board. >>> >>> Il dom 19 dic 2021, 20:21 Andrea Cosentino <anco...@gmail.com> ha >>> scritto: >>> >>>> What's the reason for having 72 hours of release window if this is not >>>> an important release but just a middle release? I don't see good reason, >>>> just a rule 20 years old, that should be revisited. >>>> >>>> Btw, David, it looks to me you're trying to create problems here. The >>>> vote will be for 72 hours. Please stop it, now. You won. >>>> >>>> Il dom 19 dic 2021, 20:06 David Jencks <david.a.jen...@gmail.com> ha >>>> scritto: >>>> >>>>> https://www.apache.org/legal/release-policy.html#release-approval < >>>>> https://www.apache.org/legal/release-policy.html#release-approval> >>>>> >>>>> I think it’s entirely appropriate that I ask why you are not following >>>>> the well known: >>>>> >>>>> `Release votes SHOULD remain open for at least 72 hours.` >>>>> >>>>> To me this means that any shorter release vote needs a good >>>>> justification. What does it mean to you? You say it’s not a critical >>>>> release, so what’s the hurry? >>>>> >>>>> David Jencks >>>>> >>>>>> On Dec 19, 2021, at 9:40 AM, Andrea Cosentino <anco...@gmail.com> >>>>> wrote: >>>>>> >>>>>> It's not a critical release i meant to say >>>>>> >>>>>> Il dom 19 dic 2021, 18:36 Andrea Cosentino <anco...@gmail.com> ha >>>>> scritto: >>>>>> >>>>>>> It's a critical release and we already done it in the past. If you >>>>> any >>>>>>> troubles we could extend to 72 hours. But i don't see why. For some >>>>> sub >>>>>>> projects we use 48 hours. >>>>>>> >>>>>>> It looks to me you're looking for problems where they don't exist. >>>>>>> >>>>>>> Let's do 72 hours. I don't want complaints. >>>>>>> >>>>>>> Il dom 19 dic 2021, 18:29 David Jencks <david.a.jen...@gmail.com> ha >>>>>>> scritto: >>>>>>> >>>>>>>> What justifies the shorter-than-standard-72-hours voting window? >>>>>>>> >>>>>>>> David Jencks >>>>>>>> >>>>>>>>> On Dec 19, 2021, at 1:27 AM, Andrea Cosentino <anco...@gmail.com> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I'll release tomorrow morning and open a vote for 48 hours, since >>>>> this >>>>>>>> will >>>>>>>>> be outside camel-k. >>>>>>>>> >>>>>>>>> Il sab 18 dic 2021, 10:05 Claus Ibsen <claus.ib...@gmail.com> ha >>>>>>>> scritto: >>>>>>>>> >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> I think it would be good to get a new release of kamelets that >>>>> works >>>>>>>>>> well with the new Camel 3.14.0 release. >>>>>>>>>> >>>>>>>>>> We did some updates to the yaml-dsl in 3.14 that requires a new >>>>>>>>>> release of kamelets to work. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Claus Ibsen >>>>>>>>>> ----------------- >>>>>>>>>> http://davsclaus.com @davsclaus >>>>>>>>>> Camel in Action 2: https://www.manning.com/ibsen2 >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>>
