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 >> >>>>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>> >> >>>>> >> >>
