It was just an example of not following the standard rule, just because it is a standard rule.
Il gio 23 dic 2021, 19:03 David Jencks <david.a.jen...@gmail.com> ha scritto: > 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 > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>> > >>>>>>>> > >>> > >>> > >
