I agree, and I would want to know the specific reason. For a security problem I’d expect the discussion and vote to be on the PMC list.
David Jencks > On Dec 23, 2021, at 9:54 AM, Andrea Cosentino <anco...@gmail.com> wrote: > > Sorry, pressed enter too fast > > https://lists.apache.org/thread/8rn1468ky9n1mnn4h4dkgvbpjjlzr6jf > > So I think, in particular situation we could cut down the time window for > specific reason, well explained. > > > > Il giorno gio 23 dic 2021 alle ore 18:54 Andrea Cosentino <anco...@gmail.com> > ha scritto: > >> About the time window for a release, in particular in case of CVE or >> security issues, we could even release in hours. >> >> There is this discussion in member mailing list >> >> >> Il giorno lun 20 dic 2021 alle ore 04:01 David Jencks < >> david.a.jen...@gmail.com> ha scritto: >> >>> 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 >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>> >>> >>>
