On Fri, 13 Jul 2018 18:30:13 +0300 Jonathan Aquilina <jaquil...@eagleeyet.net> said:
> Could we enhance the scripts to make things easier to do this? > > If that is a yes then I’m more than willing to work on enhancing the scripts Yes - we could. Though it would be a combination of workflow + scripts. You want the information to already exist in a form that a script can find/digest. i.e. in the git commit log. Then a Script can hint and extract it and format things appropriately. To some extent the info exists like @fix tags in a commit log identifying that commit as a fix to a problem that existed in prior efl releases. @feat / @feature for new features and @opt for optimizations too... The problem is making a 1 line summary that makes sense to people out of all of that. Does the shortlog do that? It should... but sometimes it just is too short to do it. Having an "expanded" sub-header section might be needed like: ---- evas - shortlog goes here +extra information on lines beginning with a plus signe +like this rest of the extended body here ---- At least I've often found it impossible to give a decent description just in a shortlog and had to expand in the first few lines of the log body. > Sent from my iPhone > > > On 13 Jul 2018, at 16:36, Mike Blumenkrantz > > <michael.blumenkra...@gmail.com> wrote: > > > > Yes, I think bugfix releases should be done much more frequently. The issue > > here is that doing releases in EFL is still very cumbersome; we need to > > greatly reduce the amount of active work that it takes to execute and ship > > a release. > > > > On Fri, Jul 13, 2018 at 3:21 AM Jonathan Aquilina <jaquil...@eagleeyet.net> > > wrote: > > > >> Some food for thought wouldn’t it be better to do more frequent point > >> releases? > >> > >> Sent from my iPhone > >> > >>> On 12 Jul 2018, at 20:12, Mike Blumenkrantz < > >> michael.blumenkra...@gmail.com> 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 would disagree with your assessment that you are the single point of > >>> failure in releases. The 1.21 release has had a lot of issues, more than > >>> any release since the 1.8 cycle in 2013. When a release fails to happen > >> on > >>> schedule as a result of community/project issues, I don't think the > >> release > >>> manager can be blamed in any way. > >>> > >>> 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. > >>> > >>> Going forward, I would really appreciate it if you could give managing > >>> releases one more try for the 1.22 cycle, 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. > >>> 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. > >>> > >>> 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. > >>> > >>> On Thu, Jul 12, 2018 at 10:33 AM Stefan Schmidt < > >> ste...@datenfreihafen.org> > >>> wrote: > >>> > >>>> Hello. > >>>> > >>>>> On 10.07.2018 07:42, Mike Blumenkrantz wrote: > >>>>> Hello, > >>>>> > >>>>> It seems that we have some issues lately regarding scheduling, > >>>> specifically > >>>>> personal schedules. We (as a project) have expectations of developer > >>>>> availability, and when these expectations are changed or not met then > >>>>> things can get a bit messy. > >>>> > >>>> Do we (as a project) really have this expectations? For me a community > >>>> project has to deal with the coming and going of developer resources. > >>>> > >>>> I tried many times to get a 1.21 release schedule set that would have > >>>> avoided my unavailability in June. All of these attempts failed and we > >>>> ended in this situation. > >>>> > >>>>> Fortunately, we have tools to avoid issues with this. > >>>>> > >>>>> https://phab.enlightenment.org/calendar/ > >>>>> > >>>>> If anyone is planning to be unavailable for a length of time which > >> could > >>>>> impact the project (e.g., going on vacation/holiday for a week, going > >> on > >>>> a > >>>>> business trip for several days when a release is pending, ...), please > >>>>> create an event on the calendar for it. The visibility for events can > >> be > >>>>> set to "committers" if anyone is concerned about privacy, and I would > >> not > >>>>> recommend providing excessive detail in the event description; a simple > >>>>> "unavailable" is enough. > >>>> > >>>> I already have a private and a business calendar I need to keep updated. > >>>> I am not keen to have another one I need to update. My work scope > >>>> changed, my travels have increased and my private time I put into this > >>>> project has also reduced due to personal changes. Even if I would say > >>>> yes here to update such a schedule this with lag behind in just a few > >>>> weeks time from now due to me not updating it. > >>>> > >>>> On the bright side though I should no longer be the single point failure > >>>> for release stuff after 1.21 is out as I will step down from the release > >>>> manager role. I tried to form a release team for many years so far but > >>>> failed in getting anyone interested. By stepping down I kind of forcing > >>>> this change, hopefully for the better. > >>>> > >>>> 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 > >>>> enlightenment-devel@lists.sourceforge.net > >>>> 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 > >>> enlightenment-devel@lists.sourceforge.net > >>> 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 > >> enlightenment-devel@lists.sourceforge.net > >> 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 > > enlightenment-devel@lists.sourceforge.net > > 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 > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com ------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
