This is wrong, from the point of view of proper process.

I'm glad you are accepting "fault", Kevin, "for not being more communicative", but the process is that we have issues that are opened in Bugzilla, work on them is coordinated in the comments of those issues, issues that we decide to include in the 4.0 release are marked with a "4.0" milestone, issues that we decide can be done after the 4.0 release are assigned a "Future" milestone, and we know when we are ready to release when all issues with a 4.0 milestone have been closed.

I don't care about being or nor being "communicative". How can anyone on the team be working on an issue and allow the issue to be closed without ever making a comment in Bugzilla and especially without reopening the issue when they see it closed?

This is not even a discussion that should be ongoing in this mailing list, other than perhaps a single email saying "Whoops, too soon for a release candidate, I have (re-)opened bug(s) #X and #Y that need more work, look at them for details."

Please properly put whatever technical reasons we have to not proceed with the release in the correct Bugzilla issues.

This has only reinforced the decision to go R-T-C: I certainly don't want to see this turn into a commit war between everything that Henrik has done in the past days vs an entire independent set of patches completed in the dark in parallel. We can hash it out in Bugzilla comments where it belongs.

 Sidney


Kevin A. McGrail wrote on 1/05/22 4:39 am:
The switch to making sure that the patches were without any issues led to
significant delays.

To my knowledge there is nobody testing the code in any live production
systems. I expect we will find bugs because of that.

As I said the fault is mine for not being more communicative. But yes right
now we have patches doing the same things in different ways with different
issues and they need to be reconciled.

Appreciate all your help on them. We'll get it done and hopefully I'm wrong
with the bugs and gaps being minimal.

Regards,. KAM

On Sat, Apr 30, 2022, 12:16 Henrik K <h...@hege.li> wrote:


Why are you expecting massive issues?  I completed all the WLBL work in few
days in meticulous detail, there's extensive tests and many people tested
it.  I think there was about one alias that was missing which Giovanni
noticed (cheers).

I would have rather not participated, but as you went silent for year or
two, why would anyone expect there's some pending diffs.

On Sat, Apr 30, 2022 at 12:03:55PM -0400, Kevin A. McGrail wrote:
Well it was out fault for working on diffs and not giving visibility.
Others
then did work on some of the same bugs in a new branch.

We are reconciling it against the same work others did on the WLBL, for
example.  And I expect with RC1 to find some pretty massive issues there
since
I don't think anybody is using all the code there.

We also found some issues with sigonly in the original version and in
other
patches too.

So we're working on bugs and reconciliation between two different
people's code
fixing the same bugs. Not easy.

Hope that clears things up and why I don't think RTC is useful for RC1
because
I don't think it has any chance of becoming a full release.

Regards, KAM






On Sat, Apr 30, 2022, 10:58 Henrik K <[1]h...@hege.li> wrote:


     Wtf?  If you or someone have "giant diffs" or work being done, then
post
     them on the appropriate bugs, reopening if necessary.  I don't
understand
     why even waste time posting something vague like this.

     On Sat, Apr 30, 2022 at 09:50:15AM -0400, Kevin A. McGrail wrote:
     > Should we delay RTC? I know there are some bugs being worked on in
some
     of the
     > bugs that have been closed. I also know there's some patches that
     Giovanni
     > might or might not have gotten to for the WLBL. We had a giant
diff for
     that
     > was collided.
     >
     > On Sat, Apr 30, 2022, 05:55 Axb <[1][2]axb.li...@gmail.com> wrote:
     >
     >     Doh! Henrik already did it.
     >     Thanks!
     >
     >     On 4/30/22 11:52, Axb wrote:
     >     > Should we update [2][3]20_aux_tlds.cf for this relesase?
     >     >
     >     > I can't do it at the moment - any taker?
     >     >
     >     > On 4/30/22 11:27, Sidney Markowitz wrote:
     >     >> It's time for a code freeze in preparation for the release
of
     4.0.0
     >     >> release candidates.
     >     >>
     >     >> Please do not commit anything to trunk other than the usual
     ongoing
     >     >> rules stuff that finds its way into the rule update process.
     >     >>
     >     >> Any new bug fixes that need to be committed for 4.0.0
should be
     >     >> associated with a bug opened with a 4.0 milestone and get
reviewed
     >     >> before committed.
     >     >>
     >     >> Please hold off on committing for any issue that is not
marked as
     4.0
     >     >> milestone.
     >     >>
     >     >> Thanks,
     >     >>
     >     >>   Sidney
     >     >>
     >     >
     >
     >
     >
     > References:
     >
     > [1] mailto:[4]axb.li...@gmail.com
     > [2] [5]http://20_aux_tlds.cf/


References:

[1] mailto:h...@hege.li
[2] mailto:axb.li...@gmail.com
[3] http://20_aux_tlds.cf/
[4] mailto:axb.li...@gmail.com
[5] http://20_aux_tlds.cf/



Reply via email to