I think your reply is exactly why we should use the calendar; you say you were sending mails about it and telling people for months before, and yet I was still unaware. Or maybe I forgot. Either way, if there had been a calendar entry then I would have known immediately.
Are you really taking that many week+ vacations that you would need to be constantly updating a calendar like this? Maybe I should be talking to my employer about doubling or tripling my PTO... I understand fully your decision to not manage 1.22, and I support you in this. We'll do our best to figure it out! On Fri, Jul 13, 2018 at 10:37 AM Stefan Schmidt <[email protected]> wrote: > Hello. > > On 12.07.2018 13:12, Mike Blumenkrantz wrote: > > Now that we're interacting more as a community, I think there is the > > general expectation that if you're a core developer then you should try > to > > notify the project if you'll be gone for an extended period of time. > > > > I agree that there is a "deal with it" aspect to a community project, > but I > > think that if a core developer will be gone for longer than maybe a week, > > then there should be some responsibility to at least alert everyone of > that > > unavailability. I don't think that's an unreasonable thing to ask? > > > > To be clear, while this mail was not directed at you, certainly your > > absence was a factor in my sending it--I didn't even know that you would > be > > gone until 1-2 weeks after you'd left. While I am not in any way blaming > > you for taking a vacation, it would have been nice to be able to check > the > > calendar on the first week that you were out and seen that you were gone. > > I honestly do not see how having a special calendar for this would > really change anything for the community here. I started months before I > my long absence to mention it in mails about the 1.21 schedule and also > directly to people. > > If there is a really big momentum where all the devs here would but > their unavailability into the calendar I can try to do that as well, but > I foresee that I will forget to update it on a regular basis. > > > I can appreciate your concerns with community involvement in the release > > process, but I don't think that "stepping down" from the position of > > release manager will solve anything. Releases in EFL have historically > been > > handicapped by many issues, but most notably--as you mentioned--by lack > of > > community collaboration. This is not specific to releases however; it's > > only recently that we've begun to come together and make a concerted > effort > > to act and behave as a real community instead of simply bickering > endlessly > > about every trivial item. > > I have a different opinion on if we only recently started to try to > behave like a community, but that is off topic for this thread. > > The time you, Marcel and others have been spending on improving the bug > tracking tagging, projects, etc is definitively helping to get the load > of release handling (as long as this is kept up for the future as well) > > > Going forward, I would really appreciate it if you could give managing > > releases one more try for the 1.22 cycle, > > Sorry, but I already got weak and handle 1.21 now (not doing the best > job either) and I swore myself to not handle 1.22. > > There is no bad blood from my side on this. I simply think that I should > stop doing it and someone else (or a group) needs to form to bring new > energy into the way we handle releases. > > and send some mails to the list > > (or create tickets) regarding things that the community can do to help > with > > releases. Everyone knows in some sense that you need help, but I think > > maybe we're all a bit unsure what we can do to contribute. > > Asking me how to help was to complicated? :-) > > > It would also be great if we could also do a bit more automation with > > releases, to reduce the active work burden on whoever is executing the > > release. I'm certainly willing to pitch in and help see if we can further > > streamline the release process, as well as discussing any changes which > > could simplify the process and avoid future cases where the release gets > > blocked for a long period of time. > > That could help. Also splitting the role of into different tasks. Not > all of them have to be done by one person. There could be a bug > wrangler, a person how runs abi-checker and analysis the report, a > person how handles release notes, etc. Lost of jobs not needed to be > done by one person alone. > > > Regardless of whether you follow through with your plan to step down from > > managing releases, I just want to say thanks for all the time and effort > > you've put into managing releases over the years. I know it wasn't easy, > > but you kept everyone (mostly) on schedule for many years, and I can't > > think of anyone who could have done it better. > > Appreciated. > > regards > Stefan Schmidt > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
